JPEG XL in Firefox 157: Add It, Don't Replace AVIF Yet

Mozilla plans to enable JPEG XL by default in Firefox 157, and Chromium has an approved intent to ship the format across its six Blink platforms. Together with Safari's existing support, that changes JPEG XL from a format most web teams could safely ignore into one they should evaluate. It does not make a site-wide conversion automatically worthwhile.

The OpenSourceChoice verdict is deliberately conservative: add JPEG XL as a negotiated source for image classes where a representative benchmark proves an advantage, but keep AVIF, WebP, or JPEG fallbacks and every source original. Do not make JPEG XL the only public asset format until the browser releases are stable, your actual clients support it, and production measurements confirm the expected gain.

The most promising early cases are high-value lossless images, large photographs that must preserve editing headroom, HDR assets, and workloads that benefit from progressive display or lossless reconstruction of existing JPEG files. AVIF may remain smaller for ordinary lossy web photographs and screenshots; Mozilla's own published examples show exactly that. The decision belongs in an image pipeline benchmark, not in a codec popularity contest.

This is a researched technical analysis of official browser announcements, standards material, repositories, release notes, security policies, test results, and public project state observed on August 26, 2026. OpenSourceChoice did not encode a production corpus, measure decoder CPU or battery use, or deploy JPEG XL to a live site. Project benchmarks and community performance claims are identified rather than presented as independent results.

Executive verdict

Why this matters now

Mozilla posted its intent on August 24. JPEG XL is currently behind image.jxl.enabled; it is enabled by default in Nightly and has been exposed as a Firefox Labs option on every channel since Firefox 152. The proposed change is to enable it for all platforms in Firefox 157. Mozilla says animation and progressive display are implemented, while HDR JPEG XL is currently rendered as standard dynamic range. The default-on change is still future work: a named release is a plan, not evidence that a stable browser has already shipped it.

Chromium published its own intent the same day. The proposal covers Windows, macOS, Linux, ChromeOS, Android, and WebView, and it received the three API-owner approvals required by the thread. It also uses jxl-rs. The intent did not name a shipping milestone when checked, and two Web Platform Test failures were still being investigated in the enabled test run. Describing Chrome support as already stable would therefore be premature.

Firefox 154.0.1 was the current stable Firefox version in Mozilla's product-details service on August 26. Developer Edition was on 155 beta and Nightly on 156. This makes the announcement actionable for pipeline planning, but not a reason to remove fallbacks today.

Interest is not limited to the two browser teams. The Mozilla announcement reached 305 points and 82 comments on Hacker News when observed on August 26. Separate discussions appeared in the Firefox and JPEG XL Reddit communities, with the larger Firefox thread showing more than 400 votes. These are independent attention signals, not proof of codec quality. GitHub activity, official implementation work, and browser interoperability tests provide the technical evidence.

No existing OpenSourceChoice article covered JPEG XL, the browser rollout, or the adoption intent behind this analysis. Recent coverage focused on storage continuity, private search, desktop recovery, AI runtimes, and hardware tooling; this article addresses a different operational decision.

What is actually shipping

JPEG XL is the ISO/IEC 18181 image-coding system. It supports lossy and lossless images, alpha, animation, wide color and high dynamic range, progressive decoding, and a reversible way to recompress many legacy JPEG files. The last feature can reduce storage or transfer without throwing away the original JPEG bitstream: a conforming workflow can reconstruct the original JPEG bytes.

Browser support is only the decoding half of the publishing system. Mozilla and Chromium are integrating jxl-rs, a Rust decoder maintained under the libjxl GitHub organization. The current jxl-rs release was 0.6.0, published August 18. Its repository describes a predominantly safe-Rust implementation with narrowly reviewed unsafe code for SIMD and performance work. The project had 79 commits in the preceding 30 days when checked, plus 14 open issues and 24 open pull requests. Those dated activity observations show active engineering; they do not establish quality by themselves.

Publishers still need an encoder. The reference implementation and command-line tools live in libjxl, whose current release was 0.12.0 from July 1. It provides cjxl for encoding and djxl for decoding. Debian packages expose libjxl-tools, Homebrew uses jpeg-xl, and the official release supplies Windows and Debian artifacts. A minimal local conversion can look like this:

cjxl input.png output.jxl --distance=1 --effort=7

--distance=0 requests lossless output. The libjxl documentation identifies roughly 0.5 to 3.0 as a useful lossy distance range, but that is a starting point, not a cross-codec quality equivalence. A quality number in one codec cannot be assumed to mean the same perceptual result in another.

The division matters operationally:

• jxl-rs is the browser-facing decoder in the announced Firefox and Chromium work.
• libjxl is the practical upstream encoder and tooling dependency for most publishing pipelines.
• JPEG XL is the standardized file format; neither GitHub repository is a hosted image service.
• A browser launch does not update an old email client, social preview crawler, office suite, native SDK, or image-processing library.

What JPEG XL does not solve

JPEG XL does not eliminate content negotiation, responsive image markup, image dimensions, cache policy, quality selection, or performance measurement. It also does not make every source smaller.

Mozilla's published examples are useful because they resist a universal winner narrative. In its tested photo and screenshot, AVIF produced smaller files at the selected web-quality settings, while JPEG XL performed better in lossless mode. Those are project-published examples, not an independent benchmark and not a representative sample of every site. Their practical lesson is that format choice should follow image class and quality target.

The format also cannot repair a poor source. Repeatedly transcoding a lossy AVIF, WebP, or JPEG derivative into JPEG XL does not restore information. Keep the original camera, design, or archival asset, and generate every delivery format from that source. JPEG reconstruction is a special reversible path for eligible JPEG files, not a general reversal of previous lossy edits.

Finally, it does not remove frontend discipline. An oversized JPEG XL can still delay Largest Contentful Paint. Missing width and height can still cause layout movement. Eager loading every below-the-fold image can still waste bandwidth. Codec adoption should be one controlled change inside a broader media budget.

The safest web delivery pattern

Start with explicit URLs and <picture>, not server-side Accept rewriting. The browser evaluates sources in order and chooses the first type and media condition it supports. The final <img> remains the compatibility and accessibility anchor.

<picture>
  <source
    srcset="/images/hero.jxl 1x, /images/hero@2x.jxl 2x"
    type="image/jxl"
  >
  <source
    srcset="/images/hero.avif 1x, /images/hero@2x.avif 2x"
    type="image/avif"
  >
  <source
    srcset="/images/hero.webp 1x, /images/hero@2x.webp 2x"
    type="image/webp"
  >
  <img
    src="/images/hero.jpg"
    width="1200"
    height="800"
    alt="Descriptive alternative text"
    decoding="async"
  >
</picture>

This ordering prefers JPEG XL only on supporting clients. Separate URLs make CDN behavior observable and avoid a Vary: Accept cache key until the team has proved that its CDN, origin, and monitoring handle variants correctly. The trade-off is temporary storage amplification: several derivatives coexist during the evaluation.

Do not automatically put JPEG XL first for every image. Generate it for the selected pilot class, and let AVIF remain first elsewhere. A template flag or image-manifest decision is easier to roll back than an opaque edge transformation rule.

The performance risk is broader than file size

The main unresolved operational question is decode cost on the images and devices that matter to you. The Chromium intent discussion included concern about lossless decoding CPU and battery use. One external comparison posted there was later corrected because its command decoded twice; maintainers also noted that libjxl's faster-decoding encoder setting can trade a small amount of compression for materially quicker decoding. This exchange identifies a real measurement dimension, but it does not provide a reliable universal ratio.

Measure at least four independent outcomes:

1. Transferred bytes: compare at matched perceptual quality for each content class, not at equal command-line quality numbers.
2. Encode cost: record CI time, memory, and the effect on preview or editorial latency.
3. Decode and render cost: test representative low-end and high-end devices, especially large lossless images and animated assets.
4. User-visible performance: observe Largest Contentful Paint, image render completion, error rate, and total page weight under production-like caching.

Progressive display can improve perceived loading without reducing total decode work. Conversely, a smaller file can be a bad result if it blocks a constrained device longer. Record both network and CPU behavior.

Current maturity and security boundary

jxl-rs 0.6.0 is active and already connected to two major browser implementations, but it remains a young, performance-sensitive decoder. The repository did not expose a dedicated SECURITY.md when checked. Direct integrators should identify the project's private reporting path before production rather than assume that a public issue is appropriate for a vulnerability.

libjxl 0.12.0 deserves a stricter gate. Its release notes include numerous overflow, out-of-bounds, and malformed-input hardening fixes and recommend using the latest version. Its security policy covers tagged releases from 0.5 onward and provides a private reporting address. Image decoders process attacker-controlled files in many systems; pinning an old converter or server-side decoder turns a format experiment into a supply-chain risk.

For a web publisher, there are two separate patch responsibilities:

• visitors receive browser decoder fixes through their browser vendor;
• the publisher owns patches for build-time encoders, server-side thumbnailers, upload validators, desktop tools, and any CDN image service.

Sandbox conversion jobs where practical, constrain input size and resource use, and do not pass untrusted uploads directly into a long-lived privileged process. The current Firefox stable branch also had its normal security-advisory cadence on August 26; browser update hygiene remains necessary even though those advisories were not JPEG XL-specific.

The public Web Platform Tests for JPEG XL and the Interop 2026 focus are encouraging because they let engines converge on observable behavior. Passing format tests is still different from proving that your pipeline preserves metadata, colors, orientation, animation timing, and quality across its own tools.

Privacy, metadata, and data flow

A locally encoded JPEG XL file does not require an analytics service, account, or vendor API. Served from the same origin or CDN as the existing image, it adds no inherent tracking request. That makes local libjxl tooling the cleanest privacy baseline.

The surrounding workflow can change that conclusion. A hosted transformation API receives source assets and may retain request logs, derivative caches, filenames, or metadata. Assess processing locations, retention, access controls, deletion behavior, and contract terms before sending private or embargoed images to one. Do not adopt such a service merely to gain a format its local open-source encoder can produce.

Metadata needs an explicit policy. Camera identifiers, timestamps, coordinates, author fields, and edit history can be sensitive regardless of the delivery codec. Test whether EXIF, XMP, and other boxes are preserved, transformed, or stripped by the exact encoder command. Preserve metadata required for rights and accessibility; remove data that should not be public.

License, governance, and lock-in

jxl-rs uses the BSD 3-Clause license. libjxl also uses BSD 3-Clause and includes an additional patent-rights grant. The JPEG committee presents JPEG XL and its reference implementation as royalty-free and open source. This is a permissive base for commercial and open-source use, but organizations with material patent exposure should still perform their own legal review.

The standard and local tools reduce format-level lock-in. You can keep source assets, regenerate derivatives, and change encoders without changing the public semantics of <picture>. The larger lock-in risk is the transformation pipeline: proprietary URL parameters, vendor-specific quality controls, hidden source storage, and a CDN asset catalog can make exit expensive even when the file format is open.

Governance is distributed across the ISO standard, the libjxl organization, and browser vendors. Repository activity and adoption by Mozilla and Chromium reduce dependence on one application team, but a numeric bus factor cannot be responsibly inferred from commit counts. Evaluate who can review security fixes, cut releases, and maintain encoder integrations relevant to your deployment.

The real operating cost

JPEG XL and its reference tooling have no license fee. The rollout still has costs:

• extra object storage and cache occupancy while JXL and fallback derivatives coexist;
• encoder CPU and longer build or editorial queues;
• dependency updates and security response for libjxl or wrappers;
• color, metadata, animation, and orientation regression testing;
• production telemetry split by browser, device, route, and image class;
• support work when external clients cannot consume the format;
• rollback capacity and periodic deletion of derivatives that failed the gate.

A simple static site with a few already optimized images may never recover that complexity. A media-heavy publisher can justify it if one high-volume content class shows a durable transfer or quality advantage.

Alternatives to evaluate in parallel

The correct comparison is not “JPEG XL versus everything.” It is a source order and operational plan that gives each client a supported asset while your own measurements decide where JXL earns a place.

A seven-step production evaluation

1. Freeze the source corpus

Select 100 to 500 representative originals and classify them: photographs, screenshots, illustrations, logos, lossless archival images, HDR, alpha, and animation. Record dimensions, source format, metadata expectations, and current delivery bytes. Do not choose only images likely to flatter the new codec.

2. Pin current tooling

Use libjxl 0.12.0 or a newer security-reviewed release, record the exact package or container digest, and save the command configuration with the build. Confirm the private vulnerability-reporting and upgrade paths.

3. Match visual outcomes

Generate JPEG XL, AVIF, and current WebP/JPEG or PNG variants from the same originals. Compare at a perceptually acceptable result for each class. Include human review for color, text edges, banding, alpha, animation, and HDR-to-SDR behavior; a single aggregate quality score is insufficient.

4. Set measurable local gates

A reasonable starting policy is to require at least a 10% byte reduction for the target class, no more than a 50 ms regression in p75 Largest Contentful Paint, no increased broken-image rate, and decode CPU inside the team's device budget. These are proposed operational thresholds, not measured JPEG XL results. Adjust them to traffic, device mix, and business value before the test.

5. Deliver reversibly

Add a JXL <source> for the pilot class, retain the current derivatives, and deploy through one template or manifest flag. Keep explicit URLs and verify the image/jxl media type. A rollback should require one configuration change, not asset recovery.

6. Test the real compatibility boundary

Cover stable Safari plus the Firefox and Chromium versions that actually enable JXL by default when they ship. Also test crawlers, social cards, email, native applications, download workflows, admin previews, content editors, accessibility tooling, and cache purges. Export JPEG, PNG, or another accepted format where a non-browser consumer needs it.

7. Decide by class, then keep watching

Promote only image classes that pass byte, quality, CPU, and reliability gates. Keep originals and regenerate on encoder upgrades. Review browser support, libjxl security releases, cache hit rates, and operational incidents before expanding the pilot.

Who should adopt—and who should wait

Adopt a controlled pilot if images are a material share of traffic, you retain high-quality originals, your pipeline can generate parallel derivatives, and you can measure real clients. Lossless-heavy publishers, high-resolution archives, and HDR-capable media workflows have the clearest reason to investigate.

Wait for stable default support if your users mainly run Firefox or Chromium stable and you cannot tolerate partial coverage. Planning and corpus benchmarking can start now; a public dependency on an announced feature should not.

Skip the rollout for now if AVIF/WebP already meet the budget, images are a small cost, external applications require universal files, or the team cannot patch image tooling and preserve fallbacks. Open source removes a license bill, not operational responsibility.

OpenSourceChoice recommendation

JPEG XL has crossed an important credibility threshold: Mozilla and Chromium are preparing default browser support around a shared Rust decoder, while Safari already provides a deployed compatibility base. That makes the format worth engineering time. It does not justify a flag-day migration.

Start with a representative corpus and current libjxl, measure by image class, and expose successful candidates through <picture> ahead of existing fallbacks. Keep AVIF as the parallel modern option, keep WebP/JPEG or PNG for compatibility, and keep every original. The primary risk is not that JPEG XL is open or undocumented; it is that a team optimizes for file size while ignoring decode cost, client coverage, cache behavior, and the maintenance of another security-sensitive image tool.

For most web publishers in August 2026, the right decision is prepare and pilot, not replace.

Sources and verification notes

Primary sources were preferred for technical claims. Social sources are listed only as dated interest signals.

• Intent to Ship: JPEG XL — Mozilla dev-platform, August 24, 2026; Firefox 157 plan, current pref state, platform scope, known HDR limitation, testing, and later Chromium-status update. Accessed August 26, 2026.
• Intent to ship: JPEG XL — Mozilla Hacks, August 24, 2026; project rationale, jxl-rs integration, progressive display, animation, and project-published AVIF/JXL examples. Accessed August 26, 2026.
• Intent to Ship: JPEG XL — Chromium blink-dev, August 24, 2026; all-platform proposal, API-owner approvals, jxl-rs integration, test status, and performance discussion. Accessed August 26, 2026.
• Firefox version details — Mozilla product-details service; stable, beta, and Nightly versions observed August 26, 2026.
• jxl-rs repository and jxl-rs 0.6.0 — libjxl organization; decoder architecture, BSD 3-Clause license, release dated August 18, 2026, and repository activity observed August 26, 2026.
• libjxl repository, libjxl 0.12.0 release notes, and security policy — reference tools, installation and encoding guidance, license and patent grant, security fixes, and supported tagged releases. Release dated July 1, 2026; accessed August 26, 2026.
• JPEG XL overview and JPEG XL work plan — Joint Photographic Experts Group; format capabilities and current ISO/IEC 18181 parts. Accessed August 26, 2026.
• WebKit Features in Safari 17.0 — WebKit, September 18, 2023; Safari support and <picture> fallback examples. Current relevance rechecked August 26, 2026.
• <picture> element reference — MDN Web Docs; source selection and fallback behavior. Accessed August 26, 2026.
• Interop 2026 JPEG XL tests and live Web Platform Test results — web-platform-tests and WPT dashboard; cross-browser test scope and current results. Accessed August 26, 2026.
• Mozilla Security Advisory 2026-74 — Mozilla, August 18, 2026; current Firefox 154 security-update context, not a JPEG XL-specific advisory. Accessed August 26, 2026.
• Hacker News discussion, Firefox community thread, and JPEG XL community thread — independent interest signals observed August 26, 2026; not used as primary technical evidence.