Every major browser engine is converging on JPEG XL. Keep your fallbacks anyway

Mozilla engineer Timothy Nikkel posted an intent to ship JPEG XL on August 24, targeting Firefox 157 for default support. Mozilla's and Chromium's intents landed within minutes. Nikkel's post listed Chrome as having no intent to ship. That was already out of date, and he appended Chromium's filing 22 minutes later. The Blink thread cross-linked Mozilla's intent too.

Safari has decoded JPEG XL since Safari 17.0 in 2023, although Mozilla says its implementation lacks animation and progressive rendering. With Gecko and Blink preparing to enable it, Mozilla expects cross-browser support before the end of 2026.

Deployment now depends on whether your users, image pipeline, and chosen JPEG XL features are ready. JPEG, WebP, AVIF, and PNG fallbacks still have work to do.

Mozilla wanted a safer decoder

Firefox added experimental JPEG XL support behind a flag in 2021, but Mozilla was uncomfortable shipping the reference decoder. The implementation added more than 100,000 lines of multithreaded C++ to a browser decoding untrusted images.

In September 2024, Mozilla platform engineer Bobby Holley challenged the JPEG XL team at Google Research to produce a Rust decoder that was safe, fast, compact, and compatible enough for production. He framed it as a way to reduce memory-safety risk across applications that might eventually support JPEG XL. The result is the jxl-rs decoder used by Firefox and Blink. Safari uses the C++ libjxl decoder.

Image decoders process hostile input and have historically been a useful attack surface. Rust removes a class of memory-safety failures, though it cannot prove the decoder has no vulnerabilities. Sharing jxl-rs also means one parser defect could affect both Gecko and Blink.

What remains unsettled before Firefox 157

Nikkel says Web Platform Tests cover decoding, color management, coding tools, and web integration points. Firefox adds about 30 lower-level tests, browser tests, performance benchmarks, and a second fuzzing pass due before the preference flips. Chromium reports two WPT failures with its flag enabled: a small visual difference for an uncommon ICC profile and a basic CMYK conversion issue whose fix is in review.

Performance remains less settled. Multithreaded decoding arrived in jxl-rs 0.6.0, with Firefox integration patches expected next. Nikkel's own benchmark, run with those patches applied, put Firefox slightly ahead of Safari's C++ decoder on his machine. Against Firefox's other formats, JPEG XL was close on large images but showed a wider gap on small ones.

Firefox does not display HDR for any image format, JPEG XL included, though Nikkel says its JPEG XL tone mapping is better than what it does elsewhere. That matters because Chromium lists HDR among the format's headline capabilities.

JPEG XL and AVIF solve different image problems

Mozilla's announcement gives teams a useful starting point instead of asking them to run an open-ended codec bake-off. JPEG XL is strongest for lossless imagery, progressive rendering, and compressing existing JPEGs further without another quality loss. AVIF tends to be stronger for web-quality photographs and images that combine sharp edges with flat surfaces.

On Mozilla's screenshot example, AVIF is 11.6 kB to JPEG XL's 23.8 kB at a SSIMULACRA 2 score of 78. Losslessly, the same screenshot is 164 kB as AVIF and 92 kB as JPEG XL. Lossless WebP is 96 kB, so JPEG XL's win over a format every browser already supports is a few percent, not a category change. AVIF has only basic progressive rendering, so JPEG XL may still be worthwhile when an early preview matters.

Treat those examples as directional. Test representative photographs, illustrations, screenshots, and transparent assets at an acceptable quality. Compare file size and perceived loading, then measure decode and processing costs against the formats already in production.

Delivery also needs negotiation. A CDN or image service can send JPEG XL to a capable client while retaining established alternatives. Cloudinary and Shopify have expressed interest in deployment, but teams still need to verify cache behavior, upload validation, social previews, and server-side transformations.

The real test starts after stable releases

Developers can test Firefox today. image.jxl.enabled is on by default in Nightly, and Firefox Labs has exposed a JPEG XL checkbox at about:preferences#experimental on every channel since Firefox 152. The enable-by-default tracking bug remains open.

Chrome exposes the decoder behind #enable-jxl-image-format. Chromium's intent cleared the three-LGTM approval bar on the day it was filed. It plans to ship enabled for all users but specifies no milestone.

The Firefox discussion on Reddit mixes enthusiasm with fatigue after years of uncertain browser support. The skepticism is fair, but the technical position has changed: all three major engines now decode JPEG XL or intend to enable it. Stable milestones, installed-browser coverage, feature parity, and the rest of the image toolchain remain the real gates. JPEG XL belongs in a test pipeline now. It does not yet justify deleting the fallback branch.