The image [...] is a 116 kB AVIF with a quality score (SSIMULACRA 2) of 62.8, meaning medium-high quality. To get the same quality, the JPEG XL image would be 134 kB.
At a SSIMULACRA 2 score of 80 (very high quality), the AVIF is 227 kB, and the JPEG XL is 264 kB.
But at lossless, the AVIF is 1.76 MB, and the JPEG XL is 1.45 MB. A lossless WebP is 1.55 MB.
At a SSIMULACRA 2 score of 78 (very high quality), the AVIF is 11.6 kB, and the JPEG XL is 23.8 kB.
But at lossless, the AVIF is 164 kB, and the JPEG XL is 92 kB. A lossless WebP is 96 kB.
Although AVIF tends to produce smaller files at web-quality than JPEG XL, AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL.
For all the furore, I think the best outcome happened here. Both browsers used their weight to get a memory-safe implementation out, and now we can all benefit from a new file format with a significantly reduced attack surface.
Agreed. Much thanks to Mozilla for taking the wildly unpopular decision to shoot the early proposal down as well instead of supporting it just because it'd make people more mad at Chrome.
Agreed. It's been hard to watch how much vitriol was pointed at Mozilla for their reasonable position. The C++ decoder was simply unsafe and they would not implement it until a memory-safe decoder was available.
Imagine if the fanatics got what they wanted immediately and then major vulnerabilities were introduced and there was a huge backlash against JXL. It could have set things back way more
> and then major vulnerabilities were introduced and there was a huge backlash against JXL.
Has that ever stopped any of the previous unsafe stuff?
Seems like this would be the same - we'd just see faster adoption of the better format without browser limits
I'm under the impression that one of the main selling points of JPEG XL is that it's backwards-compatible, so once everyone has a decoder implementation, every existing JPEG comes along for free without anyone having to reencode any old photos. I suspect consumers wouldn't notice the difference if devices started emitting them, and in the meantime that means there's no harm in continuing to emit classic JPEG for as long as you want.
smartphones, computers, and TVs also dedicated hardware acceleration for AVIF video. Decoding an AVIF image uses virtually no battery/CPU power. It will require mass adoption to convince hardware makers to dedicate chips for decoding. especially with AVIF2 on the horizon
Chrome doesn't use hardware acceleration for decoding any image codecs-- not for JPEG or WebP or AVIF. It has some code for it (using VA-API), but it's disabled by default. Hardware video decoders are generally hard to use for image decoding tasks.
Safari appears to be the only shipping browser using hardware decoding for JPEG and HEIF (HEVC based images). This is probably because vertical integration lets them make the decoders appropriate for image use.
Also, "AVIF video" is incorrect. AVIF is the image codec based on AV1 intra frames.
AVIF supports regular AV1 videos, there is no intra-only constraint. You can try this yourself with any AV1 video:
ffmpeg -i input.webm -c:v copy output.avif
You are right about Firefox and Chrome not using hardware decoding though, as such an AVIF video plays back poorly. And Chrome refuses to load an AVIF larger than 256 MB on my machine.
I'm a fan of JpegXL and happy to see support finally begin to coalesce around it on the browser scene, but I was wondering if anyone knew what goes into the decision of whether or not to consider adding encode support, e.g. via offscreenCanvas.convertToBlob() or whatever. How did browsers (minus Safari, of course) end up deciding to add support for WebP encode in addition to JPEG and PNG?
It often comes down to compat, and developer requests. Personally I find in-browser encoding for images inadequate, because it doesn't expose enough options. When we built https://squoosh.app/, we exposed the browser encoders for completeness, but they're pretty bad compared to the wasm codecs.
I love your editor/comparison tool. Would you be open to adding browser WebP?
Is the JpegXL lossless options the "transparent JPEG recompression" or the actual lossless profile? I'm presuming the latter because it more than doubled the image size.
Yeah it's the latter. I'm going to look into adding transcoding, but Squoosh is currently set up to pass a bitmap to the encoder rather than the original image, because the original image can be processed first.
I can totally see how this feature would upend most architectures. Great work, I am adding a todo list action item up see if the performance can’t work out in favor of using this in place of the browser APIs we currently run to maybe adopt it. Love what you’ve done with the package and the site (this isn’t the first time it’s come on my radar, but you’ve spurred me to actually do something about it this time).
Nice. I hope we'll see more support for jxl across the web. It's so good at this point that it's my primary output/archival format for all of my photography.
And Chromium intent to Ship: JPEG XL decoding support (image/jxl) in blink
https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDoj...
And Mozilla's blog post about shipping JPEG XL:
https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
Some background on this, and demos of JPEG XL's progressive rendering: https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
Key points (from TFA):
= = =
= = =For all the furore, I think the best outcome happened here. Both browsers used their weight to get a memory-safe implementation out, and now we can all benefit from a new file format with a significantly reduced attack surface.
Agreed. Much thanks to Mozilla for taking the wildly unpopular decision to shoot the early proposal down as well instead of supporting it just because it'd make people more mad at Chrome.
Thanks all. I'm really happy with how it all turned out.
(^CTO for Firefox at Mozilla)
Agreed. It's been hard to watch how much vitriol was pointed at Mozilla for their reasonable position. The C++ decoder was simply unsafe and they would not implement it until a memory-safe decoder was available.
Imagine if the fanatics got what they wanted immediately and then major vulnerabilities were introduced and there was a huge backlash against JXL. It could have set things back way more
> and then major vulnerabilities were introduced and there was a huge backlash against JXL.
Has that ever stopped any of the previous unsafe stuff? Seems like this would be the same - we'd just see faster adoption of the better format without browser limits
Arguably killed WebSQL and Java applets, for some past examples. Currently it's why WebUSB is not getting picked up by Safari/Firefox.
Great outcome, and I hope the weight of mainstream browser support will spur camera and phone manufacturers to emit native JXLs from their devices.
We've been here before. Jpeg and PNG are "good enough" and consumers aren't going to get behind anything that is slightly less convenient.
I'm under the impression that one of the main selling points of JPEG XL is that it's backwards-compatible, so once everyone has a decoder implementation, every existing JPEG comes along for free without anyone having to reencode any old photos. I suspect consumers wouldn't notice the difference if devices started emitting them, and in the meantime that means there's no harm in continuing to emit classic JPEG for as long as you want.
Tell that to all the users with iPhones chucking out HEIC/HEIF images by default, which are much less convenient
smartphones, computers, and TVs also dedicated hardware acceleration for AVIF video. Decoding an AVIF image uses virtually no battery/CPU power. It will require mass adoption to convince hardware makers to dedicate chips for decoding. especially with AVIF2 on the horizon
Chrome doesn't use hardware acceleration for decoding any image codecs-- not for JPEG or WebP or AVIF. It has some code for it (using VA-API), but it's disabled by default. Hardware video decoders are generally hard to use for image decoding tasks.
Safari appears to be the only shipping browser using hardware decoding for JPEG and HEIF (HEVC based images). This is probably because vertical integration lets them make the decoders appropriate for image use.
Also, "AVIF video" is incorrect. AVIF is the image codec based on AV1 intra frames.
AVIF supports regular AV1 videos, there is no intra-only constraint. You can try this yourself with any AV1 video:
ffmpeg -i input.webm -c:v copy output.avif
You are right about Firefox and Chrome not using hardware decoding though, as such an AVIF video plays back poorly. And Chrome refuses to load an AVIF larger than 256 MB on my machine.
AVIF video does support an alpha channel, which AV1, annoyingly, doesn't.
I'm a fan of JpegXL and happy to see support finally begin to coalesce around it on the browser scene, but I was wondering if anyone knew what goes into the decision of whether or not to consider adding encode support, e.g. via offscreenCanvas.convertToBlob() or whatever. How did browsers (minus Safari, of course) end up deciding to add support for WebP encode in addition to JPEG and PNG?
It often comes down to compat, and developer requests. Personally I find in-browser encoding for images inadequate, because it doesn't expose enough options. When we built https://squoosh.app/, we exposed the browser encoders for completeness, but they're pretty bad compared to the wasm codecs.
I love your editor/comparison tool. Would you be open to adding browser WebP?
Is the JpegXL lossless options the "transparent JPEG recompression" or the actual lossless profile? I'm presuming the latter because it more than doubled the image size.
Yeah it's the latter. I'm going to look into adding transcoding, but Squoosh is currently set up to pass a bitmap to the encoder rather than the original image, because the original image can be processed first.
I can totally see how this feature would upend most architectures. Great work, I am adding a todo list action item up see if the performance can’t work out in favor of using this in place of the browser APIs we currently run to maybe adopt it. Love what you’ve done with the package and the site (this isn’t the first time it’s come on my radar, but you’ve spurred me to actually do something about it this time).
I love squoosh.app! Thanks so much for making that.
I am excited for this! A great practical format.
I love progressive rendering. At 15% loaded in this example it’s surprisingly good already.
Nice. I hope we'll see more support for jxl across the web. It's so good at this point that it's my primary output/archival format for all of my photography.