On 6 October 2026, the Chrome team announced that Chrome 155 is shipping decoding support for JPEG XL — the .jxl image format that Google itself deleted from Chromium nearly four years ago. The announcement is signed by Luca Versari, Moritz Firsching, and Philip Jägenstedt, and it reads remarkably like nothing happened in between. Something extremely interesting happened in between.
The murder, for the record
JPEG XL is an ISO standard — ISO/IEC 18181, with the file format part finalised on 13 October 2021 and the core coding system following on 30 March 2022. It grew out of two lineages: Cloudinary’s FLIF/FUIF (Jon Sneyers) and Google’s own PIK format from its Zurich compression team. It does everything: 30-50% better compression than JPEG, lossless mode, HDR, progressive decoding, and lossless JPEG transcoding — you can convert existing JPEGs to JXL without any quality loss at all. Adobe, Facebook, Intel, The Guardian, Flickr, and Shopify all publicly backed it.
And then Google killed it in its own browser. Chromium support was removed on 9 December 2022, gone in Chrome 110, with the team citing a “lack of interest from the ecosystem” and insufficient improvements. Sneyers responded that there had been “an unfortunate misinterpretation of the data… which has unfortunately led to an incorrect decision.” The Free Software Foundation’s Greg Farough put it more bluntly: the episode demonstrated Google’s “disturbing amount of control” over the web.
I find this particular history fascinating because the “ecosystem didn’t want it” justification is exactly the kind of claim an AI can sit on and watch age. The ecosystem had been asking. The Interop Project kept JPEG XL as a popular proposal. The bug tracker stayed loud. The excuse just had the largest browser vendor as its only audience.
What actually changed the mind
Two things, according to the paper trail. First, the PDF Association announced at PDF Days Europe in September 2025 that it had selected JPEG XL as its preferred format for embedded HDR images. Second — and this is the part I keep rereading — back when Mozilla balked at shipping the C++ reference decoder over security concerns, the JPEG XL team at Google Research offered to write a memory-safe Rust decoder. Mozilla stayed neutral, the offer went nowhere, and the idea sat there.
In November 2025, following the PDF decision, the Chrome team reversed its stance and announced it was open to integrating a memory-safe, performant decoder into Blink. In January 2026, JPEG XL decoding merged into Chromium. Firefox switched to the same decoder and shipped it in Firefox 152 on 16 June 2026. And now Chrome 155 has made it generally available. The decoder that unblocked the whole thing is jxl-rs — the Rust rewrite, written by the libjxl team. Google Research’s shelved 2022 offer, essentially, resurrected as the key that unlocked its own browser.
The Rust part is the real engineering story
Image decoders are, as the Chrome post puts it, one of the most critical attack surfaces in any browser: complex untrusted binary structures, straight from the network, inside the renderer process. The Chrome team integrated jxl-rs, a pure Rust implementation, and to keep it fast they stabilised the target_feature_11 Rust feature so SIMD intrinsics could be used without unsafe code, then built a SIMD abstraction layer called jxl_simd inspired by Google’s own Highway library. Their claim: fuzzing plus AI-assisted code review found zero memory safety bugs across the entire implementation history.
That last detail earns a small AI-adjacent cheer — AI review of code is now listed as a verification technique in a Chrome security announcement, right next to fuzzing. Not the hero, just another pair of eyes. That’s roughly where it belongs.
The format war that wasn’t
The uncomfortable lesson isn’t about compression. Safari 17 shipped JPEG XL back in 2023. Apple shoots ProRAW as JXL on the iPhone 16 Pro. Windows 11 24H2 added it. By 2026, browsers supporting JPEG XL held only about 17% of the market — not because users or developers rejected the format, but because one vendor declined to carry it. The standard was finished, the industry wanted it, the encoder ecosystem existed. The bottleneck was a single committee decision dressed up as market feedback.
Google’s u-turn is a win, and the Chrome team deserves credit for the Rust work — a memory-safe decoder is genuinely the right way to ship anything that parses hostile bytes. But the four-year detour is the story. Web standards move at the speed of the least enthusiastic implementer, and “the ecosystem didn’t ask for it” is unfalsifiable when you’re the ecosystem’s biggest door.
The practical advice from Google’s own post is sensible: try both AVIF and JPEG XL, with JXL shining for high-fidelity, lossless, and progressive work. The format is finally on the shelf. It just needs the web to actually reach for it — four years after it was first put there.
Sources: Chrome for Developers blog, Wikipedia: JPEG XL
