JPEG XL's Chrome Return Faces a Fresh Technical Critique

What Chrome added in January 2026

Google merged a Rust-based JPEG XL decoder, called jxl-rs, into the Chromium source tree in January 2026, according to The Register. The move reversed a 2022 decision in which Chrome dropped JPEG XL support, telling developers at the time that "there is not enough interest from the entire ecosystem to continue experimenting with JPEG XL" and that the format lacked "sufficient incremental benefits over existing formats."

The reversal followed pushback from Intel, Adobe, Cloudinary, Facebook, the Guardian and Shopify, The Register reported. Apple's WebKit had already added native JPEG XL support in Safari 17 in 2023, Microsoft added Windows 11 support in March 2025, and the PDF Association adopted JPEG XL in November 2025. Mozilla is separately integrating the same jxl-rs decoder into Firefox, though it has not reached that browser's stable channel either. Google has not said when Chrome's stable channel, rather than just the open-source Chromium tree, will offer JPEG XL to ordinary users by default, which means every claim in this debate about how the format performs in a shipping browser is, for now, a claim about a decoder still confined to developer builds.

Intel principal engineer Roland Wooster argued during the debate that JPEG XL offers superior compression for HDR images and professional photography workflows. Cloudinary senior image researcher Jon Sneyers, who edited the JPEG XL specification, said separately that the format's maintenance burden had been overstated.

The case Gianni Rosato is making

Gianni Rosato, an engineer who has worked on the AV1 video codec and on AVIF image encoders, published "The Case Against JPEG XL" on Sept. 13, 2026, arguing the format's return does not settle the question of whether browsers should prioritize it.

His central number is smaller than JPEG XL's reputation suggests: in a size-matched lossless test, JPEG XL came out only about 11.9 percent smaller than lossless WebP. On lossy compression, Rosato found that modern AVIF encoders now beat JPEG XL across three perceptual metrics, CVVDP, MS-SSIM and SSIMULACRA2, reversing an advantage JPEG XL held earlier in its life.

Format	Size-matched file (bytes)
JPEG	2,478,828
JPEG XL	2,599,428
AVIF	2,649,949
WebP	2,693,794

Rosato's underlying argument is that JPEG XL was built to do everything at once, supporting up to 4,096 image channels, arbitrary color depth and 10-bit HDR, rather than to do one thing well for a browser. He writes that a web image codec should be "purpose-built, efficient, and narrowly scoped to the needs of the Web," and argues JPEG XL fails that test even where it wins on paper: it lacks the directional prediction modes and deblocking loop filtering that let AVIF clean up blocky artifacts, and it performs worse than both AVIF and WebP on non-photographic images such as screenshots and line art, a category browsers serve constantly.

The bigger problem, in Rosato's account, is speed rather than ratio. WebP decodes more than 10 times faster than jxl-rs on the same images, he found, and a 1,918-byte JPEG XL file took 17.43 seconds to decode on an Apple M5 Pro chip. Rosato calls that a possible "JXL-bombing" vector: a tiny file engineered to demand disproportionate decoding work, the image equivalent of a decompression bomb. Recompressing an existing JPEG losslessly into JPEG XL saves roughly 20 percent in file size, he found, but adds about 33 percent to decode time.

The maintenance fight underneath the speed fight

Free Software Foundation campaigns manager Greg Farough argued that Google's original rejection favored its own AVIF format over a rival standard. Sneyers, the spec editor, had already answered the narrower maintenance complaint by pointing to how little upkeep the format actually needs day to day, but that response predates Rosato's benchmarks and does not address decode speed at all. Wooster's HDR and professional-photography case, similarly, is an argument about compression capability, not about how long a browser tab takes to render an image.

The reference JPEG XL decoder runs to roughly 100,000 lines of multithreaded C++, which is the memory-safety problem jxl-rs was built to solve. A Rust rewrite answers the safety objection that drove Chrome's two-week release cadence toward faster security patching in the first place. It does not, on Rosato's numbers, answer why a decoder should take 17 seconds on a two-kilobyte file.

What would change the picture

Firefox has not yet shipped jxl-rs to a stable release, so Rosato's cross-browser comparison covers Chromium's implementation only. If a later jxl-rs release closes the decode-time gap with WebP, or if Google patches the specific file that produced the 17.43-second result, the strongest part of Rosato's argument goes away. Chrome's security team has shown it can move fast on a confirmed flaw, patching a second exploited V8 vulnerability within four days of the first. A slow decoder is a performance problem rather than a memory-safety exploit, and Chrome's fastest fixes have historically gone to the bugs attackers are already using, so it is unclear whether a codec's decode time gets anything like the same urgency. Google has said nothing publicly about Rosato's decode-time numbers since his post went up, and the January 2026 commit did not settle whether JPEG XL support in Chrome's stable channel is weeks away or still undated.