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.
show comments
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.
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.
show comments
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.
show comments
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.
tepmoc
One downside is that you cannot tell if format lossy or lossless by looking at its extension.
show comments
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.
show comments
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...
show comments
flockonus
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.
I remember in 2023 jpeg xl was dropped from Chrome for reasons I assumed at the time to be political
This had a cascading effect, where we immediately (within hours) dropped support for jpegxl on Pixel Camera and various other Google products
Synaesthesia
So it's supported now by all the major browsers (Firefox support coming soon) as well as all the major OSes.
show comments
Bender
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.
show comments
hdjrudni
Yay! Good timing. I just integrated JXL into my photo gallery website a few days ago. Non-optional. I can't afford to be hosting Jpegs :-) Now I don't have to tell people to flip the flag in their settings.
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:
Not to be a downer — it's one necessary step on the road.
show comments
mkesper
Caution: Apparently, machine translation still sucks: "memory-unsafe languages like C++" gets auto-translated to "speichersicheren Sprachen wie C++" in German which means the exact opposite.
show comments
computerbuster
I wrote "The Case Against JPEG XL". I still don't understand why this is a valuable addition to the Web, to be honest.
1. Lossy: AVIF is vastly more efficient at any fidelity target with reasonably modern encoders (libaom, SVT-AV1). Even proprietary WebP encoders are more efficient than libjxl. More efficient meaning better quality at the same size. This is provable even beyond modern metrics.
2. Lossless: JPEG XL is ~10-13% better than WebP here, but can be >6x slower to decode. What is the point of saving 10% bits when the client pays for it? There are lossless codecs more efficient than both that are faster to decode than both, too.
3. JPEG Recompression: Same deal, the increased decode time often erases the time-to-display gains (even on modern devices) - not just me either, this was proved empirically in the previous HN thread on a Pixel 9 Pro.
4. AVIF can have as many progressive decode passes as you like, and they aren't just "layers", they actually work together.
There are strengths, like 32-bit float precision and support for a lot of layers. I'm just lost on what the criteria for including a new codec in the Web is at this point. Google was heavily involved in JXL's development so I understand their incentives exist, and the "all-in-one" codec argument, but other than that, I'm a bit lost.
show comments
eviks
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?
show comments
Waterluvian
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."
Evidlo
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.
show comments
moritzwarhier
Google's AI translations really have come a long way...
"memory-unsafe languages like C++"
is translated as
"speichersicheren Sprachen wie C++"
(flipping the adjective's meaning)
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.
herf
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?
show comments
arikwald
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?
show comments
llm_nerd
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.
show comments
tsuru
Any way for those who enjoy dynamic languages (non-Python) to call it via FFI?
codingjoe
Is this the same patent/license nightmare as JPEG2000 ?
show comments
chuliomartinez
Is jpegxl support in canvas toBlob planned?
show comments
anonymous344
how about an option to block that "update address?" dialog on domain basis???
Markoff
It's all nice, but kinda pointless since pretty much all preinstalled phone cameras shoot either in JPEG, RAW or HEIF and if you can't host it without recompressing, then it's not very useful for the heaviest files, which are usually photos.
show comments
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.
show comments
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.
show comments
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?
show comments
dev1ycan
Now kill WEBP.
tristor
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.
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!
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.
One downside is that you cannot tell if format lossy or lossless by looking at its extension.
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.
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%
The timetable looks promising: https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong...
I remember in 2023 jpeg xl was dropped from Chrome for reasons I assumed at the time to be political
This had a cascading effect, where we immediately (within hours) dropped support for jpegxl on Pixel Camera and various other Google products
So it's supported now by all the major browsers (Firefox support coming soon) as well as all the major OSes.
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.
Yay! Good timing. I just integrated JXL into my photo gallery website a few days ago. Non-optional. I can't afford to be hosting Jpegs :-) Now I don't have to tell people to flip the flag in their settings.
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.
Caution: Apparently, machine translation still sucks: "memory-unsafe languages like C++" gets auto-translated to "speichersicheren Sprachen wie C++" in German which means the exact opposite.
I wrote "The Case Against JPEG XL". I still don't understand why this is a valuable addition to the Web, to be honest.
1. Lossy: AVIF is vastly more efficient at any fidelity target with reasonably modern encoders (libaom, SVT-AV1). Even proprietary WebP encoders are more efficient than libjxl. More efficient meaning better quality at the same size. This is provable even beyond modern metrics.
2. Lossless: JPEG XL is ~10-13% better than WebP here, but can be >6x slower to decode. What is the point of saving 10% bits when the client pays for it? There are lossless codecs more efficient than both that are faster to decode than both, too.
3. JPEG Recompression: Same deal, the increased decode time often erases the time-to-display gains (even on modern devices) - not just me either, this was proved empirically in the previous HN thread on a Pixel 9 Pro.
4. AVIF can have as many progressive decode passes as you like, and they aren't just "layers", they actually work together.
There are strengths, like 32-bit float precision and support for a lot of layers. I'm just lost on what the criteria for including a new codec in the Web is at this point. Google was heavily involved in JXL's development so I understand their incentives exist, and the "all-in-one" codec argument, but other than that, I'm a bit lost.
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?
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.
Google's AI translations really have come a long way...
"memory-unsafe languages like C++"
is translated as
"speichersicheren Sprachen wie C++"
(flipping the adjective's meaning)
After some time, this seems to be the first image format, now in production, not being just the nus product of some video format.
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?
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?
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.
Any way for those who enjoy dynamic languages (non-Python) to call it via FFI?
Is this the same patent/license nightmare as JPEG2000 ?
Is jpegxl support in canvas toBlob planned?
how about an option to block that "update address?" dialog on domain basis???
It's all nice, but kinda pointless since pretty much all preinstalled phone cameras shoot either in JPEG, RAW or HEIF and if you can't host it without recompressing, then it's not very useful for the heaviest files, which are usually photos.
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 kill WEBP.
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
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…