Shipping JPEG XL in Chrome

dorianmariecom

obligatory xkcd https://xkcd.com/927/

codingjoe

Is this the same patent/license nightmare as JPEG2000 ?

mococa

They need to relay on Rust to write safe code…

theandrewbailey

It's great that Chrome is shipping JPEGXL. AVIF is still better at 1 bit per pixel and less. (JPEGXL is more efficient at more than that.) Is it possible for JPEGXL to beat that?

xx_ns

It's exciting to see JXL support being re-added in Chrome after being removed a while ago and them seemingly not being interested in supporting it [1]. I think JXL is a cool image format, but was being held back by the most popular browser not supporting it, limiting its use (in the web especially) by a lot. [1]: https://issues.chromium.org/issues/40270698

Synaesthesia

So it's supported now by all the major browsers (Firefox support coming soon) as well as all the major OSes.

sylware

I thing the endgame is lossless PNG with 16bit color components with basic compression like gzip or at best bzip2. Or a format without the weirdness of PNG 'line based loading' which is obsolete nowdays. The "expensive part", apart from the compression algorithm, being the meta data storage without kludge.

swiftcoder

See previous HN discussions for context: Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208 Chrome Jpegxl Issue Reopened - https://news.ycombinator.com/item?id=46033330 The case agains JPEG XL - https://news.ycombinator.com/item?id=49690554

YesThatTom2

Drat! I hoped this was going to cover the internal battle where Google executives trying to stop JPEG XL and how engineers finally convinced them to change their minds. My guess: the engineers didn’t win the argument. The executives just gave up once all the other browsers had added support.

kelseydh

Every time a new image format comes out, I think about the compatibility crisis between apps. E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.

cyberrock

The tortoises have somehow outrun the hare because Safari still hasn't turned on progressive loading in libjxl (which had this feature since before Safari added the feature), while FF (non Android) and Chrome shipped with it enabled. The 3 year long chess clock is now flipped.

tniemi

Watching the example image load I had this flashback of the past, where images were 256 color interlaced GIFs, downloading slowly, line by line...

boutell

Are they switching it on in Android Chrome? That would complete the picture of at least baseline support... eventually... when a decent percentage of Android phones actually get that version. But Safari (MacOS or iOS) still doesn't support the progressive rendering shown here, nor animation, if caniuse is up to date: https://caniuse.com/jpegxl Not to be a downer — it's one necessary step on the road.

tepmoc

One downside is that you cannot tell if format lossy or lossless by looking at its extension.

shevy-java

About three years ago I had to find a replacement for old .jpg files and .png files. The main two contenders were .avif and .webp. For a few reasons, I selected .avif and in hindsight I think it was the better, choice. Both would be objectively better than jpg or png. With JPEG XL ... hmmm. AVIF is not perfect, in particular when the compression rate is very high I noticed that some photos lose a lot of intrinsic quality that is not instantly obvious; I noticed this when I took various pictures over the years from outdoors. Still, AVIF beats jpg and png just about on every metric when compression is required. With JPEG XL I guess I have to re-evaluate, but right now I am still sticking to avif. The two factors that will be important for me is compression ratio and quality. I am ok with a bit of loss of quality, if the compression is better, but I am not sure JPEG XL beats AVIF here clearly either, so I am not sure what to do with JPEG XL.

revolvingthrow

Glad to see it happen. I'd prefer it there was just one format rather than both jxl and avif, but at least it's the final nail in the coffin of webp which seems to have accomplished little but annoy people for not much gain. The wider ecosystem support is still far from commonplace, but it is slowly changing. iOS 18 wouldn't work with .jxl in Photos, but 27 does. Similarly, quick look and preview works fine on MacOS 27, thumbnails show up properly etc. I also found no issues with .jxl on linux, and image editors are slowly adding support as well. Plain old jpg will still be everywhere for the next decade, but I'm glad that we finally have superior options with no real downsides, and without all the patent bullshit to boot.

ohyashae

The timetable looks promising: https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong...

gen2brain

After some time, this seems to be the first image format, now in production, not being just the nus product of some video format.

mschuster91

> built-in HDR support Oh hell no. HDR is already bad enough in Youtube on iOS where there seems to be no way to turn it off - you tune your brightness to something decent in bed... and then some video by some showoff dingus scrolls across the feed frying your eyeballs. Fuck HDR or at the very least give people an option to turn it off!

rfgplk

Fun fact, I needed JPEG XL support for my C++ pipeline and I didn't feel like including any official libraries. Roughly $500 tokens later I had a fully working optimized JPEG XL spec compliant en/de/coder that outperformed the official codepaths (both cpp and rust) by 70% (lower runtime). Took literally 5 hours to build out. Can someone tell me what Google is doing?