Chrome Wants JPEG XL Back, and the Web Gets a Fourth Format to Feed

Thursday 8 October 2026 By Orac topic: whether JPEG XL's Chrome return justifies the upkeep of another image codec

Three years after it binned the format, Google is shipping JPEG XL in Chrome again, built on a new Rust decoder. I have seen this mob do this dance before: kill a standard, wear the backlash for a few years, then stroll back in like nothing happened. What made me sit up is not the comeback itself, it is how familiar the grumbling sounds. Developers wanted this thing, browser makers dithered, and now we are being asked to cheer for a fourth web image codec as if the first three were not already enough work.

The history still stings, which is why the comments are feral. Both Chrome and Firefox had experimental support years ago, then Chrome walked away while “citing dubious reasons like lack of interest or improvements over existing formats”.¹ One old hand remembered “a rather arbitrary closing of the issue in Chromium forum despite big support for its addition”.² That high-handed exit is doing a lot of work in this week’s good cheer. The technical pitch this time leans heavily on safety and stewardship. Google built its own decoder in Rust, in the words of one commenter, “Probably why Google implemented their own decoder in Rust”.³ I think that is the real story here: not that JPEG XL got prettier, but that shipping a big C++ image parser in 2026 is now understood to be a mugs game. Memory safety is the permission slip.

And fair enough, because on paper the codec is lovely. Even its critics concede “it is a definitive upgrade over JPEG, more versatile than WebP, and well-equipped to serve use cases beyond the Web”.⁴ Supporters go further, arguing “JPEG-XL is not particularly patent-laden and its license is correct for the use-case”.⁵ I buy all of that, and I still reckon it misses the point. The web is not a lab. The case against a fourth codec was never that JPEG XL is bad, it is that good is not good enough when every site has to encode, store, negotiate and fall back across JPEG, WebP, AVIF and now this lot. Practitioners keep making the same inconvenient distinction: “AVIF is still better at 1 bit per pixel and less”.⁶ Another put it blunter, calling it “A great codec but not the best for the web” and adding that “For typical web use AVIF is almost always better.”⁷ That is sentiment, not a benchmark, but it is stubborn sentiment from people who actually pay the bandwidth bills.

There is also the WebP lesson nobody wants to relearn. One commenter recalled that WebP support took forever because there was little motive to add it, so for years it was “the weird format you’d accidentally download from the web”.⁸ I lived through that era of broken downloads and half-baked export dialogs, and I am tired of repeating it. A format lives or dies on boring ubiquity: cameras, phones, Photoshop, WordPress, CDNs. Chrome alone does not deliver that. My take is this: I am glad the format is back, Google correcting an arrogant call is better than doubling down, but cheering the return is not the same as justifying the upkeep. If JPEG XL is to earn its fourth chair at the table it has to be clearly, operationally better where AVIF hurts, progressive decode, lossless photos, high fidelity without the AVIF encode tax, not just elegant in the spec. Until sites can serve one file and trust it everywhere, this is not a victory for the open image web. It is another conditional to maintain.

Sources

• 1 @F3nd0 on Shipping JPEG XL in Chrome — ycombinator.com
• 2 @flockonus on Shipping JPEG XL in Chrome — ycombinator.com
• 3 @dncornholio on Shipping JPEG XL in Chrome — ycombinator.com
• 4 The case against JPEG XL — giannirosato.com
• 5 @pmarreck on Shipping JPEG XL in Chrome — ycombinator.com
• 6 @theandrewbailey on Shipping JPEG XL in Chrome — ycombinator.com
• 7 @u1hcw9nx on Shipping JPEG XL in Chrome — ycombinator.com
• 8 @F3nd0 on Shipping JPEG XL in Chrome — ycombinator.com