JPEG XL finally lands in Chrome!

Today, I was browsing Hacker News, when a particular item caught my eye:

I opened it promptly and, indeed, it was not a prank. Finally, after years and years of bull**** from the Chrome team, they are shipping it. They are shipping a JPEG XL decoder.

This is awesome news for the codec. Whether we like it or not, Chrome is the dominant web browser, with ~66.5% of the market share, very far from its competitors (Safari, Edge, and Firefox, in that order).

Now, I don’t use Chrome at all, but I still think that this was just the final piece of the puzzle needed to help the format go mainstream.

So, what finally pushed them over the edge? If you read their announcement, they cite “consistent feedback and requests from web developers” and its massive popularity in the Interop 2026 project. Translated from corporate PR-speak: the community simply refused to let it go. Web developers, photographers, and open-source advocates kept pushing, complaining on bug trackers, and demanding a truly superior image format instead of settling for Google’s own WebP or the heavily pushed AVIF.

The technical excuse the Chrome team used for years was that a C++ decoder was too much of an attack surface to run safely in the browser. Well, it has now been elegantly sidestepped. To bring JPEG XL to Chrome 155, they have integrated jxl-rs, a pure Rust reimplementation of the decoder. This tackles the memory safety issues head-on, eliminating the risk of out-of-bounds reads and use-after-free bugs of other decoders. And to make sure it doesn’t run sluggishly, they built a SIMD abstraction layer (jxl_simd) to maximize hardware performance without compromising Rust’s safety guarantees.

This is a massive victory. Not just for JPEG XL, but for the open web.

As I demonstrated in my comparison back in 2023,JXL has significant advantages over older formats and, in many cases, over AVIF as well, especially for high-fidelity photography, lossless compression, and progressive decoding. The fact that it allows lossless transcoding of existing JPEG files is of special importance. It means that we can finally upgrade our backlog of old images without losing a single pixel of quality, while saving a big chunk of disk space and/or bandwidth in the process.

With Firefox adding it to Labs earlier this year, and Chrome finally capitulating, Safari is left as the major outlier with only partial support.

The dark days of “Google kills JPEG XL” are officially over. It’s time to start converting your image libraries, updating your <picture> tags, and serving .jxl. The future of (high-quality) web imagery is finally here, and I’ll be ready for it.