The Chrome team has shipped decoding support for JPEG XL in Chrome 155, enabled by default, which would be routine news except for the history. Google removed JPEG XL from Chromium back in 2023, targeting M110, with stated reasons that included insufficient ecosystem interest and the maintenance burden of keeping an experimental decoder around. Three years later the format is back in the world’s most used browser, and Firefox 158 is scheduled to enable it by default on October 13. Within a year, all three major engines support a format one of them formally abandoned.
The reversal did not come from a product pivot. It came from developer pressure, channeled through the Interop Project, where JPEG XL was a popular proposal in the 2026 round, plus a quietly important implementation detail: the decoder Chrome ships is jxl-rs, a memory-safe pure Rust implementation, not the C++ libjxl reference. That Rust decoder was originally built by Google Research after Mozilla challenged the JPEG XL team to produce a safe, compact, performant decoder. A C++ image decoder is a standing attack surface; a Rust one removes the class of memory-corruption bugs that has historically plagued image parsing. Mozilla’s own standards position had objected specifically to the cost of adding another C++ decoder, and Firefox’s implementation is built on the same jxl-rs. The security argument unlocked the compatibility argument.
What JPEG XL actually offers
The format is standardized as ISO/IEC 18181 and royalty-free. Its headline features: 30 to 50 percent better compression than JPEG, lossless compression, progressive decoding, high bit depths, wide gamut and HDR, transparency, and animation. WebKit’s Safari 17 post quantified the familiar use case: recompressing existing JPEG files into JPEG XL is lossless and averages around 20 percent smaller, while compressing from originals can land up to 60 percent below JPEG.
The lossless JPEG transcode deserves more attention than it gets, because it is unique among the modern formats. A .jxl file created this way carries the original JPEG’s bitstream, so the exact original JPEG can be reconstructed from it byte for byte. For photo archives, that means you can shrink storage today without ever being wrong about reversibility. Apple already went further and uses JPEG XL inside the iPhone 16’s ProRAW DNG container, and DNG 1.7 and LibRaw support it, so the pro-photography side of the pipeline has been quietly using the format for two years.
Be honest about the competition, though. Mozilla’s benchmark data in its intent-to-ship post shows AVIF producing smaller files at typical web-quality settings, on one test image 11.6 kB versus 23.8 kB, while JPEG XL wins decisively at lossless, 92 kB versus 164 kB. The Chrome team’s own recommendation matches that shape: keep AVIF for lossy web imagery, and reach for JPEG XL when you need high fidelity, lossless, or fine-grained progressive rendering.
A note on how serving works, since content negotiation trips people up. The registered media type is image/jxl with the .jxl extension, and the format has a distinctive magic number (0xFF 0A), so detection is trivial. Client negotiation goes through the standard Accept header, which means any origin that already ships AVIF with Vary: Accept can bolt on a JXL variant without new infrastructure, provided the CDN in front of it does not strip Vary. That is the same pattern Cloudinary and Fastly automate; doing it yourself is a build-step away with libjxl or the jxl-rs tooling.
The rollout picture
Chrome 145 first reintroduced decoding behind a flag in February 2026; Chrome 155 turned it on by default. Safari has supported it since 17.0 in 2023, with the caveat that Safari’s support skips progressive decoding and animation. Firefox follows next week. Server-side, the picture is uneven in the usual way: Cloudinary’s f_auto already negotiates JPEG XL and delivers roughly a billion JXL images a day, Fastly’s Image Optimizer added full support in 2024, while Cloudflare’s Image Resizing still does not convert to JXL, though it will cache JXL variants from your origin via Vary: Accept. No smartphone or camera ships a hardware JPEG XL encoder, which is the real ceiling on camera-capture adoption.
For your own site, the practical sequence: add a .jxl source to your picture element behind AVIF and ahead of JPEG, keep AVIF as the workhorse for lossy photos, and re-run your own benchmarks on representative images rather than trusting anyone’s sample set, including mine. If you manage a large JPEG archive, test lossless transcoding first; it is the highest-value, lowest-risk win and it reverses cleanly if you change your mind.
The bigger story is procedural. A platform vendor removed a format, the ecosystem pushed back through the standards process, a memory-safe implementation removed the security objection, and the format returned. That is a decent template for how browser decisions should get revisited, and a good sign that Interop proposals reflect what developers actually want rather than what vendors find convenient to build.