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.
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.
JPEG-XL is not particularly patent-laden and its license is correct for the use-case.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s.
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however.
I think QuickTime 7 had that capability (I remember installing a codec to make it play wmv video) but Apple removed the plugin architecture in QuickTime X.
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.
> The executives just gave up once all the other browsers had added support.
The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.
My guess is that Apple supporting it natively in iOS (there's an option in iPhone 16+ to save taken photos as JPEG-XL instead of Apple's proprietary format) likely also pushed the needle
They added enough fear/uncertainty/doubt around jpeg xl that no sane organization will adopt it now. God Google might decide to remove support again in 2027
This is indeed frustrating, though realistically not that big of a deal for most users, especially if you consider lossless as just highest quality. Though personally I think it makes sense to have different extensions by convention for lossless and animated images.
That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.
I've been wishing for years that all of these codecs with hybrid lossless/lossy modes would just add a single l to their file extensions, purely for the annoyance of it.
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
I have a feeling that progressive loaders got downgraded along the way for whatever reason. I remember seeing progressive JPEGs and PNGs also load... progressively. JPEG even often had a grayscale-like first layer.
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:
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.
That isn’t my experience. I tried compressing conference proceedings into thumbnails with tiny file size and for this purpose I found that JPEGXL is far better than AVIF
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.
>without the weirdness of PNG 'line based loading' which is obsolete nowdays
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
These days I favour lossless WEBP instead of PNG. I often save around 30%~40% of file size compared to PNG, especially when the PNG is encoded with lots of bits per pixel (i.e 48 bits or 24 bits).
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
> removed a while ago and them seemingly not being interested in supporting it
Removed because nobody benifits from supporting it.
Re-added because someone got a promotion by supporting it.
Wasn't it due to poor security? libjxl had notorious bugs that would've on par with webp exploit, if present in browser:
https://security.snyk.io/vuln/?search=libjxl
I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.
Probably why Google implemented their own decoder in Rust
https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...
“Their own” is a bit misleading. It’s largely a subset of the people who implemented libjxl in the first place, but this time in Rust.
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.
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
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.
JPEG-XL is not particularly patent-laden and its license is correct for the use-case.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
How about AVIF?
I have not read that many direct comparisons here.
Yeah. Here is a surprisingly readable article on all the supported features and design decisions of JPEG XL: https://arxiv.org/abs/2506.05987
The format is designed to as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats.
For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations.
Ugh. Every time I accidentally put a HEIC on my Windows machine, or one of my students tries to upload a WEBP to our school's LMS :/
The user's OS or the LMS should offer to convert it on the spot. Worst case to .bmp
It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s.
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however.
I think QuickTime 7 had that capability (I remember installing a codec to make it play wmv video) but Apple removed the plugin architecture in QuickTime X.
If I remember correctly Instagram didn't support WebP either.
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.
> The executives just gave up once all the other browsers had added support.
The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.
My guess is that Apple supporting it natively in iOS (there's an option in iPhone 16+ to save taken photos as JPEG-XL instead of Apple's proprietary format) likely also pushed the needle
You made me check. iOS only supports JXL in ProRAW mode, which (I hope) most people don't use.
I thought the reasoning was Google wanted to cartel their own fledgling webp format and didn't want to promote competition?
Google is one of the main developers of Jpeg XL.
They added enough fear/uncertainty/doubt around jpeg xl that no sane organization will adopt it now. God Google might decide to remove support again in 2027
One downside is that you cannot tell if format lossy or lossless by looking at its extension.
This is indeed frustrating, though realistically not that big of a deal for most users, especially if you consider lossless as just highest quality. Though personally I think it makes sense to have different extensions by convention for lossless and animated images.
That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.
ah, that's a good point.
perhaps use .ll.jxl to indicate "lossless jpegxl" informally?
prior art: I've been using .frontmatter.md or .fm.md for markdown files with frontmatter
I've been wishing for years that all of these codecs with hybrid lossless/lossy modes would just add a single l to their file extensions, purely for the annoyance of it.
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
Watching the example image load I had this flashback of the past, where images were 256 color interlaced GIFs, downloading slowly, line by line...
I have a feeling that progressive loaders got downgraded along the way for whatever reason. I remember seeing progressive JPEGs and PNGs also load... progressively. JPEG even often had a grayscale-like first layer.
So it's supported now by all the major browsers (Firefox support coming soon) as well as all the major OSes.
I believe it's been available in Firefox for a while now, just behind a feature flag
Next up: Phones and cameras. It would be so great to have a common image format again after years of fragmentation.
The timetable looks promising: https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong...
After some time, this seems to be the first image format, now in production, not being just the nus product of some video format.
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.
Is this the same patent/license nightmare as JPEG2000 ?
No, JPEG XL is an open standard.
"open" in the sense that you have to pay $200 to read it, anyway.
That's good to hear. Let's hope there's hardware adoption on the camera end soon. As an image lib maintainer the codec wars were driving me nuts.
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.
It's great that Chrome is shipping JPEGXL.
AVIF is still better at 1 bit per pixel and less. Is it possible for JPEGXL to beat that?
That isn’t my experience. I tried compressing conference proceedings into thumbnails with tiny file size and for this purpose I found that JPEGXL is far better than AVIF
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.
>without the weirdness of PNG 'line based loading' which is obsolete nowdays
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
These days I favour lossless WEBP instead of PNG. I often save around 30%~40% of file size compared to PNG, especially when the PNG is encoded with lots of bits per pixel (i.e 48 bits or 24 bits).
I believe 7zip outdoes bzip2 these days along every metric
And lossless jpeg-xl exceeds your idea
obligatory xkcd https://xkcd.com/927/
They need to relay on Rust to write safe code…
is that a bad thing?