News: 1768351922

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Google rekindles relationship with jilted JPEG XL image format

(2026/01/14)


Google has added support for the JPEG XL (JXL) image format to the open source Chromium code base, reversing a decision in 2022 to drop the technology.

A recent [1]commit to integrate and enable the JXL decoder means that future releases of Google Chrome and other Chromium-based browsers will include code to process and present JXL images.

The format's supporters argue JXL can be used to recompress existing JPEG images without loss so they're 20 percent smaller, which alone would represent a significant bandwidth saving for websites and content delivery networks.

[2]

It also offers other improvements over existing image file formats, like progressive decoding that prioritizes salient image elements – as [3]noted in 2021 by Google engineers – and [4]better lossy and lossless compression than formats like AVIF, MozJPEG, and WebP.

[5]

[6]

[7]JPEG XL [PDF] began with a call for proposals in 2017. It started taking shape in 2019 through an effort to combine Cloudinary's Free Lossless Image Format (FLIF) with Google's PIK. It was standardized as ISO/IEC 18181 in 2021 and [8]revised in 2024 .

Google Chrome and Mozilla Firefox initially implemented experimental support for JXL behind a settings flag in 2021, based on the possibility that JXL might be able to replace older JPEG and PNG formats.

[9]

A year later, Google Chrome engineers abandoned the [10]open source image format by [11]claiming "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL."

They also argued the format “does not bring sufficient incremental benefits over existing formats to warrant enabling it by default." And they said that removing experimental support for the JXL code would reduce the maintenance burden.

In a 2023 [12]blog post , Greg Farough, campaigns manager for the Free Software Foundation, implied that Google's disinterest in JXL reflected its preference for "its own patented AVIF format." AVIF is [13]governed by The Alliance for Open Media , an industry group whose members include Google.

[14]

Google's assertion about lack of interest in the technology was promptly challenged in the Chromium bug tracking discussion. Many of the 500+ comments in the thread disputed Google's claim and cited numerous companies that had expressed interest in broader support for JXL.

[15]Developer writes script to throw AI out of Windows

[16]Court tosses appeal by hacker who opened port to coke smugglers with malware

[17]Anthropic Claude wants to be your helpful colleague, always looking over your shoulder

[18]Cloudflare CEO threatens to make the Winter Olympics a political football after Italy slugs it with a fine

Roland Wooster, principal engineer for Intel's client computing group, said at the time that Intel and its partners saw JXL as the best option for high dynamic range (HDR) still images and urged the Chrome team to reconsider.

"JPEG XL appears to be the only format with suitable compression for images on the web, 16-bit per color channel, and support for the color gamuts widely used by DSLR/MLC photographers, e.g. ProPhoto and other wide color gamuts capable of representing the color range captured by cameras," he [19]wrote on August 24, 2022.

"Beyond the critical requirements, JPEG XL also supports other highly important features: lossless compression options for archival usage, progressive image download for efficient web display, and based on others’ research appears to have class-leading compression rates, and superior image quality at the compression rates typically used for still images. No other format provides all of these important features for still images."

Representatives from other companies like [20]Adobe , [21]Cloudinary , [22]Facebook , [23]The Guardian , and [24]Shopify echoed Intel's enthusiasm for JXL.

As for the purported maintenance burden, Jon Sneyers, senior image researcher at Cloudinary and editor of the JPEG XL spec, [25]said in a November 2022 post that work required would be modest, amounting to little more than "occasionally bumping up a version number in a build script" to match a decoder library revision.

It took several more years for the message to sink in. In June 2023, Apple demonstrated its interest in the technology when it [26]implemented support in WebKit for Safari 17. In September 2024, a member of Mozilla's Firefox team said the team would consider adopting JXL once a Rust-based decoder is available, citing safety concerns about the 100K lines of multithreaded C++ code within the reference [27]libjxl decoder. That Rust-based alternative decoder, [28]jxl-rs , is making progress.

Microsoft added support for JXL in Windows 11 version 24H2 in March 2025. And in November 2025, the PDF Association [29]added JXL support to the spec.

That same month, on the mailing list for its Blink rendering engine, Google finally [30]signaled its intention to integrate a memory-safe JPEG XL decoder in Chromium. That's jxl-rs. Now, two months later, integration has arrived. ®

Get our [31]Tech Resources



[1] https://chromium-review.googlesource.com/c/chromium/src/+/7184969

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aWlxoX_y7R55PK-AJ0adJAAAANY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[3] https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-JPEG%20XL-images.html

[4] https://cloudinary.com/blog/the-case-for-JPEG%20XL

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aWlxoX_y7R55PK-AJ0adJAAAANY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aWlxoX_y7R55PK-AJ0adJAAAANY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://arxiv.org/pdf/2506.05987

[8] https://www.iso.org/standard/85066.html

[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aWlxoX_y7R55PK-AJ0adJAAAANY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[10] https://github.com/libjxl/libjxl

[11] https://issues.chromium.org/issues/40168998#comment85

[12] https://www.fsf.org/blogs/community/googles-decision-to-deprecate-JPEG%20XL-emphasizes-the-need-for-browser-choice-and-free-formats

[13] https://aomedia.org/press%20releases/the-alliance-for-open-media-statement/

[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aWlxoX_y7R55PK-AJ0adJAAAANY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[15] https://www.theregister.com/2026/01/13/script_removes_ai_from_windows/

[16] https://www.theregister.com/2026/01/13/dutch_port_hacker_appeal/

[17] https://www.theregister.com/2026/01/13/anthropic_previews_claude_cowork_for/

[18] https://www.theregister.com/2026/01/12/cloudflare_vs_italy/

[19] https://issues.chromium.org/issues/40168998#comment65

[20] https://issues.chromium.org/issues/40168998#comment62

[21] https://issues.chromium.org/issues/40168998#comment71

[22] https://issues.chromium.org/issues/40168998#comment17

[23] https://issues.chromium.org/issues/40168998#comment68

[24] https://issues.chromium.org/issues/40168998#comment80

[25] https://cloudinary.com/blog/the-case-for-JPEG%20XL

[26] https://webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/#images

[27] https://github.com/libjxl/libjxl

[28] https://github.com/libjxl/jxl-rs

[29] https://www.theregister.com/2025/11/10/another_chance_for_jpeg_xl/

[30] https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NmOyvMCCBAAJ

[31] https://whitepapers.theregister.com/



NIIIICCEEEEE!

Jou (Mxyzptlk)

Jpeg-XL is really great. Especially if you use the command line tool cjxl, which lets you control a lot more.

One of the best things: JPEG are transcoded, i.e. lossless conversion into .JXL. And the decode tool can convert the .JXL back to the .jpeg as it was before. All lossless. Already saved me tons of gigabyte space (i.e. yes, terabyte range space saved).

Same for other formats as well: Most of the time .JXL compresses better. Not always of course :D. I have quite a number of .GIF which get larger, most notably old dilbert comics. But .PNG / .TIF downloads from ESA and NASA, which can be 50 MB and much larger (I have some in the gigabyte range), are often lossless compressed to less than 50% of their original size.

Great to have it back in the current dominating browser engine.

Good thing! You won't have to worry about any new Dilbert comics!

elDog

I guess proper respect should be paid to Scott Adams who gave us some humorous views of a type of office life. Who has now passed.

And also left a legacy of right-wing craziness in his writings.

Re: Good thing! You won't have to worry about any new Dilbert comics!

Jou (Mxyzptlk)

And reacted thin-skinned the worst way. I have ALL free dilbert comics, mirrored them with a script early enough. And after his sulky locking himself into the room I only had to get about ten of the last free available via archive.org - and did not care about whatever non-free he might have posted later. But the 90% of the older .GIFs get larger as .JXL, see [1]Issue 727 . But I would have to retry with the current version, simply did not have the time though, and the possible space gain would not be much anyway.

[1] https://github.com/libjxl/libjxl/issues/727

Re: Good thing! You won't have to worry about any new Dilbert comics!

I am David Jones

Wtf i came here and learnt he died yesterday. RIP, dear fellow

mark l 2

I think it was the decision by the PDF association to add JPEG XL to their spec that pushed the Chromium devs to reconsider their decision. As if Chromium/Chrome wants to continue having the ability to open PDF document going forward then it would need to be able to decode any JPEG XL images contained within them. And if your implementing the decoder for the PDF reader then you may as well just enable it for the whole browser.

This whole things goes to show that although Chromium might be open source when its main developers are from Google they are going to follow what their business daddy wants them to do, rather than what is good for the rest of the internet.

"I'd love to go out with you, but I have to stay home and see if I snore."