JPEG XL Lands in Firefox 157: What Changes in Your Image Pipeline

Firefox will enable JPEG XL decoding by default in version 157, due at the end of September 2026, and Chrome and Edge have formalized their intent to flip the same switch for all users; Safari has shipped the format since 2023. Mozilla announced it in an intent-to-ship published August 24 with a clear conclusion: the format will be supported across all three engines before the end of the year. For teams that ship image-heavy sites, this stops being an enthusiast debate — JPEG XL becomes a real layer of your image delivery strategy, and the question is no longer "do browsers support JXL?" but "what do I gain or lose by adopting it?"

The short history of a format that left and came back

JPEG XL (ISO/IEC 18181) was designed as the modern successor to JPEG: lossy and lossless compression, lossless recompression of existing JPEG files, progressive decoding, 32-bit HDR, and animation. Firefox added experimental support behind a flag back in 2021, but the reference decoder was roughly 100,000 lines of multithreaded C++, and Mozilla refused to take on that attack surface. So it made a public bet: the JPEG XL team at Google Research had to build a decoder in Rust — safe and fast — and Firefox would ship it.

That decoder is jxl-rs, and it changed the format's story twice. First in 2022, when Chrome removed JPEG XL entirely, arguing there wasn't enough interest — a decision the community fought for years. Then in November 2025, when Chromium formally reversed course and accepted Google Research's Rust decoder. Chrome 145 (February 2026) brought JPEG XL back, though behind a flag. Now Firefox closes the loop: according to the intent-to-ship published by Jake Archibald on Mozilla Hacks, Firefox 157 turns JPEG XL decoding on by default on all platforms, powered by jxl-rs — version 0.6.0 is multithreaded, and in Mozilla's internal benchmarks it matched or beat Safari's C++ decoder on large images. The same post confirms Chrome is also intending to ship.

The real support picture (September 2026)

The detail that matters most to us as an agency: the convergence happens this quarter, not in 2027. Chrome's and Firefox's two-week release cadences mean the "supported everywhere" window closes faster than most teams project. The day Chrome flips the flag to default, a <picture> with JXL first will reach more than 85% of users with no extra fallback work.

What each format wins (and why it's not a war)

The honest read, consistent between Mozilla's own note and independent coverage like Web Standards' summary: AVIF still wins for photography at low-to-medium lossy bitrates; JPEG XL wins everywhere else.

Three practical implications that don't show up in the tables:

1. Lossless recompression is an immediate opportunity. Any existing JPEG can be converted to JXL and shrink ~20% with pixel-identical output, reversible at any time. For e-commerce catalogs, photo galleries, and media archives, that's bandwidth savings with zero quality negotiation. It doesn't require waiting for Chrome to enable anything: serve it as progressive enhancement.
2. Progressive decoding changes perceived speed. AVIF and WebP render when the download finishes; JXL shows a low-res version while the rest arrives. On slow connections — the reality for much of Latin America — the perceived difference is bigger than the byte difference.
3. Fast encoding lowers pipeline cost. Generating JXL variants is orders of magnitude cheaper in build time than AVIF, which makes pre-generating the format viable without inflating site build times.

What we're doing at Mintec (and what we recommend)

Our production baseline is AVIF-first: on the 2,500+ page editorial site we built in Astro, every image ships in 5 variants (AVIF, WebP, and JPEG in two sizes), and the pipeline cut originals from 5 MB to ~40 KB served, with a 73% build-time reduction by delegating galleries to CDN on-the-fly transforms. That architecture — the same one we documented in our AVIF vs WebP guide for Astro — adapts to JXL without redesign. Here's the plan we're validating with clients:

1. Pre-generate JXL only for the assets that matter. Heroes, product shots, and visible galleries — no need to convert the whole catalog at once. Encoding speed makes it cheap.
2. Serve with <picture> ordering type by priority — image/jxl first, then image/avif, image/webp, image/jpeg — plus Accept-header negotiation where the CDN supports it. The browser decides; nobody gets a broken image.
3. Apply lossless recompression to legacy JPEG files first: an immediate ~20% gain without changing a single URL or risking quality. It's the easiest business case to get approved.
4. Measure with field metrics, not bytes. Our hypothesis to validate: progressive decoding improves perceived LCP on slow connections even when weight is similar. Until Chrome flips the global flag, JXL should be tested against Safari plus flag-enabled Chrome traffic. And if server-side encoding becomes the bottleneck, client-side processing with native APIs — the same approach we already use for video thumbnails with Web Codecs — is a path that needs no extra infrastructure.

One warning we learned the hard way: image pipelines are also attack surface. The security argument that killed JXL in 2022 (unsafe C++) was resolved with Rust, but every new format you add to your CDN is code processing untrusted bytes — Next.js's August 2026 security bulletin showed a remote code execution from a malicious AVIF image in libheif. Version your decoders, audit your processing components, and never let an un-audited transformation script touch user uploads.

Conclusion: the image quarter

The sequence is clear: Firefox 157 enables JXL by default in September, Chrome has formalized its intent, and Safari already ships it. Before the end of 2026, JPEG XL will be the third universal modern format — and the only one with lossless JPEG recompression, progressive decoding, and HDR. This isn't the moment to migrate everything to JXL by default; it's the moment to build the JXL layer as progressive enhancement, starting with recompressing your existing JPEG archive. Teams that have the variant ready when Chrome flips the flag will cut ~20% of catalog bandwidth with zero quality loss; the rest will start a migration with the site already in production.