Chrome Spent 5 Years Telling Everyone Nobody Wanted JPEG XL. In 2026 It Shipped It Anyway

For about 5 years, the story of JPEG XL was a case study in how one company’s decision can stall a web standard that nearly everyone else wanted. Google added experimental support to Chrome, removed it while claiming the ecosystem was not interested, and spent years pointing people toward a competing format it had helped create. Then, in October 2026, Chrome 155 shipped JPEG XL decoding anyway, built on a new decoder written in Rust. The format that was supposedly unwanted is now in the browser that said nobody wanted it. I want to walk through how that happened, because the public reasons given at each step did not hold up.

What JPEG XL actually is

JPEG XL is a modern image format standardized by the JPEG committee itself, with the core coding system finalized on 30 March 2022. By Chrome’s own description, it offers 30 to 50% better compression than ordinary JPEG, lossless compression, built-in HDR support, and progressive decoding, where a browser can show a low resolution version of an image first and sharpen it as more data arrives.

The feature that matters most for the existing web is lossless JPEG transcoding. You can take the billions of ordinary JPEG files already out there and repack them as JPEG XL with no quality loss, shrinking them by around 20%, and convert them back to the exact original bytes later if needed. A format that can losslessly shrink the entire existing stock of web images by a fifth is not a small thing.

Figure 1. What JPEG XL offers over ordinary JPEG. Chrome cites 30 to 50% better compression, plus lossless recompression of existing JPEG files at around 20% smaller with a byte-exact way back, HDR, and progressive decoding. Source: Author chart based on Chrome’s developer announcement

Where it came from

JPEG XL is not a Google invention, which is part of why the story stings. It grew out of 2 separate projects that the JPEG committee merged. Jon Sneyers, an engineer at the image company Cloudinary, built a lossless format called FLIF in 2015 and then a successor called FUIF, the Free Universal Image Format. Google, separately, built a format called PIK. When the JPEG committee put out a call for proposals in 2018, FUIF and PIK were 2 of the 7 submissions, and in January 2019 the committee chose to combine them. The 2 teams then spent about 2 years merging the designs into the single format.

That history shows up in how the format works. JPEG XL has 2 modes under the hood. A VarDCT mode handles lossy photographic images using a block transform descended from the same math JPEG uses, but with variable block sizes from 2x2 up to 256x256, and it traces back to Google’s PIK. A modular mode handles lossless images, progressive loading, and extra channels like transparency, and it traces back to Sneyers’ FUIF. The compression gains come from combining these, which is why JPEG XL can cover everything from a tiny icon to a huge HDR photograph in a single format. The reference software that implements it is an open source library called libjxl.

The flag, then the reversal

Chromium added JPEG XL support behind an experimental flag on 1 April 2021, around the same time Firefox did. It was not advertised, just a thing you could switch on to try. That lasted about 18 months. On 31 October 2022, a Google engineer posted the reasons Chrome would remove it, and the list is worth reading closely because each point was later undercut.

The 4 stated reasons were that experimental flags should not remain indefinitely, that there was not enough interest from the entire ecosystem to keep experimenting with JPEG XL, that the format did not bring sufficient incremental benefits over existing formats to warrant enabling by default, and that removing the code in Chrome 110 would cut maintenance work and let Google focus on existing formats. Support was pulled from Chromium on 9 December 2022.

The ecosystem that supposedly was not there

The second reason is the one that drew the most anger, because the interest was documented, in the same discussion thread, before the removal was announced. Meta said on the record that Facebook was eagerly awaiting full JPEG XL support in Chrome. An engineer on Adobe’s Photoshop, Camera Raw, and Lightroom teams said JPEG XL was the best available codec for broad distribution of HDR still photos. Intel was on the thread. So were Shopify, Cloudinary, Flickr, SmugMug, the Krita Foundation, Serif, and The Guardian.

That is a social network with billions of users, the company that makes the dominant professional image software, a chip maker that produces a large share of the world’s CPUs, a major e-commerce platform, and a national newspaper, all asking for the format, before Google said the ecosystem did not want it. Whatever ecosystem Google was describing, this was not a niche with no backers. The gap between the stated reason and the visible evidence is what turned a routine deprecation into a multi-year grievance.

Figure 2. A sample of the companies publicly backing JPEG XL in the Chromium thread before Google said there was not enough ecosystem interest. The list spans social media, creative software, chip makers, e-commerce, and news. Source: Author chart based on the Chromium issue thread and reporting

The AVIF question

A lot of the anger centered on a conflict of interest. The main rival to JPEG XL is AVIF, an image format derived from the AV1 video codec, and Google was heavily involved in creating AV1. Removing JPEG XL while steering developers toward AVIF looked, to a lot of people, like a company favoring its own format over a committee standard that outperformed it in important cases. The Free Software Foundation went further, with Greg Farough criticizing Google for holding a disturbing amount of control over the web.

The performance picture was genuinely mixed, which muddied the argument. JPEG XL tends to win at higher quality settings, while AVIF often looks better at low quality, where it hides compression artifacts more effectively, and some of that gap comes down to the encoders, not the formats themselves. Jon Sneyers, one of JPEG XL’s creators, argued Google had misread its own test data. The honest summary is that the 2 formats traded wins depending on the test, which makes not bring sufficient incremental benefits a hard claim to defend when a major browser was simultaneously shipping the rival.

The rest of the world moved without Google

While Chrome sat out, the format kept spreading, and the spread reached well past other browsers. Apple added JPEG XL to Safari 17, which meant support across iPhones, iPads, and Macs in one move, a chunk of the market no smaller than the ecosystem Google claimed was missing. It went deeper than the browser too. The iPhone 16 Pro can capture its ProRAW photos as JPEG XL, and Samsung’s Expert RAW on Galaxy phones uses it as well, both built on the DNG 1.7 camera raw specification that added JPEG XL compression in 2023.

The software support piled up in parallel. Adobe added JPEG XL to Lightroom and to Photoshop from version 26.8, and GIMP, Krita, Affinity, ImageMagick, and FFmpeg all handle it. Windows 11 supports it through a Microsoft image extension, and Linux desktops read it through GNOME, KDE, and COSMIC. In September 2025 the PDF Association named JPEG XL its preferred format for embedded HDR images. By the time Chrome reconsidered, the format was a normal option in cameras, phones, operating systems, and professional image tools. The only conspicuous hole in the map was the browser with the largest share.

Figure 3. JPEG XL adoption outside the browser while Chrome sat out. Apple ProRAW on the iPhone 16 Pro, Samsung Expert RAW, Windows 11, Adobe, GIMP, Krita, FFmpeg, and the PDF Association for HDR all supported it before Chrome shipped. Source: Author chart based on JPEG XL adoption records

Mozilla’s position shifted too. Firefox stayed neutral through 2023, unwilling to be the driving force but open to adopting JPEG XL if it gained traction. By 2024 Mozilla had focused its concern on the security of the original C++ reference decoder and signaled it would support a Rust implementation. That detail turned out to matter, because it previewed exactly the condition Chrome would later set.

Figure 4. The 5 year timeline. An experimental flag in 2021, removal in 2022, Safari shipping it in 2023, Chrome reversing its position in 2025, a Rust decoder merged, and Chrome 155 shipping it in 2026. Source: Author timeline based on Chromium, Safari, and Mozilla records

The story changed from no one wants it to we want it in Rust

After roughly 2 more years of silence, Chrome’s position moved. On 21 November 2025, Rick Byers of the Chrome team posted that since JPEG XL was last evaluated, Safari had shipped support, Firefox had updated its position to neutral and willing to adopt, and developer signals kept coming in through bug votes, interop proposals, and survey data, with JPEG XL also being added to PDF. Given those signals, Chrome would welcome contributions to integrate a performant, memory safe JPEG XL decoder, and with long term maintenance committed and the usual launch criteria met, it would ship it.

The objection had quietly changed. It was no longer that the ecosystem did not care, because it plainly did. The new requirement was a decoder written in Rust, replacing the existing C++ one. That is a reasonable engineering ask on its own, image decoders are among the most attacked surfaces in a browser, processing untrusted binary data from the network, and memory bugs there are dangerous. The awkward part is that the organization asking for the Rust decoder, and saying it could not simply build one itself, is Google, whose employees lead the Chromium project. A company that size presenting itself as unable to resource the work read as disingenuous to many watching.

How it finally shipped

Someone built the decoder. jxl-rs, a JPEG XL decoder written in pure Rust, was merged into Chromium, and the flag became available in Chromium 145. To match the speed of the C++ version, the team leaned on recent Rust features, stabilizing the ability to run SIMD acceleration without unsafe code and building a SIMD abstraction layer called jxl_simd, modeled on the C++ Highway library. The result is a decoder that is roughly as fast as the memory unsafe alternative while removing the class of memory bugs that plague C++ decoders. Chrome’s team said fuzzing and AI assisted review found no memory safety issues in the implementation’s history.

On 6 October 2026, Chrome engineers announced that Chrome 155 would ship JPEG XL decoding. The recommendation to developers is pragmatic, try both AVIF and JPEG XL and use whichever gives better results for a given image, with JPEG XL expected to help most for high fidelity or lossless photographic images and for progressive decoding. You serve it through a picture element with a fallback format, so browsers that do not support it still get a working image.

What this actually shows

The technology was never really the problem. The decoder could have been written in Rust years earlier, the compression gains were real the whole time, and the ecosystem that Google said was missing was sitting in the comment thread with its name attached. What the saga shows is how much power over a web standard sits with whoever controls the dominant browser, and how a stated reason can function as cover for a preference, in this case for a format the same company had a hand in.

The part worth taking from it is that the pressure worked. Apple shipping Safari support, Mozilla moving to neutral, and years of developers refusing to let the issue die left Chrome with a position that was hard to hold. Plenty of formats die quietly when Google declines to support them. This one did not, because the people who wanted it kept showing up, and eventually the browser that said no had to change its answer.