And soon Firefox will include it in Stable. During October it will go from Safari only to majority coverage. Eventful month!

While AVIF may have a slight edge in some cases like in fairly lossy compression, you won't really go _wrong_ with JPEG XL (unless strongly CPU constrained) and I think the strength of the format is its extreme versatility as a "be all end all image format" for some time where comparative performance depending on functionality ranges from respectable to excellent. It can work as a replacement for AVIF, PNG, JPEG, WebP, even certain TIFF required scenarios (high bit depth, multichannel, layers) depending on use cases.

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

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

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.

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.

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.

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.

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

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

Interesting win for a cool format, i remember there was a rather arbitrary closing of the issue in Chromium forum despite big support for its addition, more strange yet is that Chrome team was pushing it's technical advancement forward.

Sadly, still far from adoptable today's web: https://caniuse.com/jpegxl = 17% https://caniuse.com/?search=webp = 97%

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

Took them long enough with a few embarassing detours, but a welcome news nonetheless! Has anyone ~blogged about some of the internal dynamics that lead the G ship to course-correct, would be curious to read?

Nice. I added support for JXL to a low traffic chan board after Firefox added experimental support. I would honestly be surprised if anyone ever upload anything in that format but I can see some use cases for it after reading this thread. I am curious if some day JXL would ever be as popular as JPG or PNG and what would drive that change. Art sites perhaps? Maybe DeviantArt could add support for it.

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

I love the codec and am glad to see it supported again. They overcame the security issues using a rust SIMD port. I wonder what "approximately as fast as the best non-memory-safe alternative" means - the wording suggests they didn't beat the C++ implementation, but how close is it?

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.

Excellent, I wanted to ask whether this release will support in Android WebView and iOS WKWebView components as well? Or only the Google Chrome browser will support this feature?

I'll kind of miss (not actually) the early 2000s codec vibe I get when I share an image with people on Signal and half of them say, "I can't view it."

Wanted to use this for building a viewer for astronomical imagery but the decoder resamples to 8 bits internally unfortunately.

Have to stick with AVIF which supports up to 12 bits.

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

Any way for those who enjoy dynamic languages (non-Python) to call it via FFI?

how about an option to block that "update address?" dialog on domain basis???

Is jpegxl support in canvas toBlob planned?

Is this the same patent/license nightmare as JPEG2000 ?

Kind of orthogonal, but note that JXL creation tools are still uneven. Affinity, for instance, has terrible JXL creation. I don't know what they're using, but it's glitchy, and yields horrible compression levels relative to the quality, and I know a number of people that were soured on JXL purely because Affinity is a poor source for it.

For that tool you need to output an uncompressed target and use the reference command line tools, preferably libjxl and cjxl (which is still the reference, while jxl-rs remains the experimental), to create the JXL. You will have better compression with better quality, minus the glitches.

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.

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.

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?

Now I just want Flickr to support uploading JXL since I do JXL export as my primary long-term storage format for final images. Would be great if Canon also added JXL support to their photo printer software.

> 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!

what a terrible name

[flagged]

[flagged]

[flagged]

[dead]

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

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?

They need to relay on Rust to write safe code…