Google *unkills* JPEG XL?

The latter post started with a quick support test:

“If you’re browsing this page around 2023, chances are your browser supports AVIF but not JPEG XL.”

Well, here we are at the end of 2025, and that sentence still rings true. Unless you’re one of the 17% of users who use Safari^{Or are adventurous enough to use a specific browser like Thorium or LibreWolf, chances are you’ll see the AVIF banner in green and the JPEG XL image in black/red.}

The good news is that this will change soon. In a dramatic turn of events, the Chromium team has reversed this Obsolete tag, and have decided to support the format in Blink (the engine behind Chrome/Chromium/Edge). Given Chrome’s position in browser market share, my guess is that the format will become D factor Standard for images in the near future.

let’s recap

I’ve been following JPEG XL since its experimental support in Blink. What started out as a promising feature was quickly killed by the team in a bizarre and ridiculous way. First, they asked for feedback on the draft from the community. Then, the community responded very positively. And I don’t just mean some guy in the basement. Meta, Intel, Cloudinary, Adobe, ffmpeg, libvipsKrita, and many more. Then came this infamous comment:

da…@chromium.orgda…@chromium.org

#85 October 31, 2022 12:34 am

Thank you all for your comments and feedback regarding JPEG XL. We will remove the JPEG XL code and flags from Chromium for the following reasons:

• Experimental flags and codes should not persist indefinitely
• There is not enough interest throughout the ecosystem to continue experimenting with JPEG XL
• The new image format does not bring enough incremental benefits compared to existing formats to enable it by default
• By removing the flag and code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome.

yes right, “There is not enough interest from the entire ecosystem“. Sure.

Anyway, after this comment, a steady stream of messages from all the organizations mentioned above and many others pointed out how wrong it was. People were paying attention to blog posts, videos, and social media interactions.

Strangely, the next few years were quite quiet for JPEG XL. However, some notable events occurred. At first, the Firefox team showed interest in the JPEG XL Rust decoder, after stating their stance on the matter was “neutral”. They were concerned about the increased attack surface resulting from the inclusion of the current 100K+ lines of C++ libjxl Reference decoder, even though most of those lines are test code. In any case, he requested a kind of “memory-safe” decoder. This seems to have kick-started Google Research’s Rust implementation, jxl-rs.

On top of that, a few weeks ago, the PDF Association announced its intention to adopt JPEG XL as the preferred image format in its PDF specification. Peter Wyatt, CTO of the PDF Association, expressed his desire to include JPEG XL as the preferred format for HDR content in PDF files.

Chromium’s new stance

This ever-increasing pressure over time forced the Chromium team to rethink the format. They tried to end it in favor of AVIF, but it didn’t work. Rick Byers, on behalf of Chromium, left a comment in the Blink Developers Google group about the team welcoming a performant and memory-safe JPEG XL decoder to Chromium. He said the change in stance was in light of the positive signals from the community we highlighted above (Safari support, Firefox updating its status, PDF, etc.). Shortly thereafter, the Chromium issue status was changed to Obsolete To Assigned,

About JPEG XL

This is great news for the format, and I believe it will give it the final push for mass adoption. The format is excellent for all kinds of purposes, and I will immediately adopt it for the Gaia Sky website when support is sent. Some of the features that make it better than the competition are:

• Lossless recompression of JPEG images. This means you can re-compress your current JPEG library without losing information and benefit from a ~30% reduction in file size for free. This is a great feature that no other format has.
• Support for wide gamut and HDR.
• Support for image sizes up to 1,073,741,823×1,073,741,824. You’ll never run out of image space. AVIF is ridiculous in this aspect, with a maximum limit of 8,193×4,320. WebP goes up to 16K²While the original 1992 JPEG supports 64K²,
• Maximum 32 bits per channel. No other format (except the defunct JPEG 2000) provides this.
• Maximum 4,099 channels. Most other formats support 4 or 5, except JPEG 2000, which supports 16,384.
• JXL is highly resilient to generation loss.
• JXL supports progressive decoding, which is essential for web delivery, IMO. There is no such feature in WebP or HEIC. Progressive decoding was added to AVIF a few years ago.
• Support for animation.
• Support for alpha transparency.
• Depth map support.

For a full codec feature analysis, see Battle of the Codecs.

conclusion

JPEG XL is the future of image formats. It checks all the right boxes, and it checks them well. Support in the hugely popular browser engine is probably going to be a significant step towards stardom for this format. I’m glad the Chromium team reconsidered including them, but I’m sad it took so long and there was so much community pressure to achieve this.