{"id":48123,"date":"2025-06-17T16:16:33","date_gmt":"2025-06-17T20:16:33","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=48123"},"modified":"2025-06-17T21:01:42","modified_gmt":"2025-06-18T01:01:42","slug":"chrome-doesnt-support-jpeg-xl","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/06\/17\/chrome-doesnt-support-jpeg-xl\/","title":{"rendered":"Chrome Doesn’t Support JPEG XL"},"content":{"rendered":"

Jim Bankoski<\/a> (2022):<\/p>\n

Helping the web to evolve is challenging, and it requires us to make difficult choices. We’ve also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?<\/p>

After weighing the data,  we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment.  We’ll work to publish data in the next couple of weeks.<\/p>

For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.<\/p><\/blockquote>\n\n

Jon Sneyers<\/a> (2023, via Hacker News<\/a>):<\/p>\n

In early April 2021, the Chrome browser added experimental support (behind a flag), even before the JPEG XL standard was officially published. (The final draft had been submitted to ISO, but it would still take until March 2022 before it was approved and published as the international standard ISO\/IEC 18181.) Firefox followed suit quickly and added experimental support. Things were looking good.<\/p>

Then, on Halloween 2022, Chrome developers suddenly announced that they would be removing JPEG XL support. This decision was quite unexpected and controversial. In my blog The Case for JPEG XL<\/a>, I argued why this decision should be reversed. In December, Chrome developers provided test results that were used to justify the decision and invited feedback. I analyzed the results and pointed out<\/a> several methodological flaws and oversights. So far, my feedback has been ignored.<\/p>

Beyond browsers, adoption of JPEG XL continued, in particular in image authoring software like Serif Affinity, Adobe Camera Raw, GIMP, Krita, etc. Unfortunately, Chrome’s decision has slowed wider adoption in web browsers of JPEG XL.<\/p><\/blockquote>\n\n

Ernie Smith<\/a> (via Hacker News<\/a>):<\/p>\n

The JPEG file format has served us well. It’s been difficult to remove the format from its perch. The JPEG 2000 format, for example, was intended to supplant it by offering more lossless options and better performance. The format is widely used by the Library of Congress<\/a> and specialized sites like the Internet Archive<\/a>, however, it is less popular as an end-user format.<\/p>

Other image technologies have had somewhat more luck getting past the JPEG format. The Google-supported WebP<\/a> is popular with website developers (and controversial<\/a> with end users). Meanwhile, the formats AVIF<\/a> and HEIC<\/a>, each developed by standards bodies, have largely outpaced both JPEG and JPEG 2000.<\/p><\/blockquote>\n\n

JPEG XL seems better, but even Apple’s not supporting it everywhere yet.<\/p>\n\n

Previously:<\/p>\n