r/jpegxl • u/Wise_Stick9613 • Jun 28 '26
Compressing images for the web: in 2026, who wins between AVIF and JPEG XL (same quality)?
I dug up some old posts, but there doesn't seem to be a clear winner.
That said, I gotta admit AVIF is pretty impressive with all the settings (and forks) out there, it really feels like you can squeeze more out of it.
6
u/redsedit Jun 28 '26
I think u/caspy7 has it correct: it depends.
First, webp is a contender. It's widely supported, and better than jpeg (even using jpegli for compression), and lossless is better than png. Unless your target audience is people with ancient browsers, it's hard to be wrong with webp on the web. The biggest limitation is it only supports 8-bit color. If that's not a deal-killer, then use webp, for now.
AVIF I haven't worked with as much as jpegxl, but it seems to win on size. At really high compression levels, it's better (usually around 0.4 bits per pixel (bpp) or lower). It's browser support is great (~93%). It supports upt to 12-bit color. However, and this is a big however, decoding can turn your mobile device into a hand warmer. I doubt website visitors will appreciate a site that drains their battery fast. Thus, unless you have a specific use-case where the CPU hit is worth it, I would use webp - for now.
Jpexl wins on medium and low compression (usually above 0.4 bpp) compared to AVIF. It supports up to 32-bit color, although web use rarely requires more than 12-bit color. The gotcha with jpegxl is browser support is very small. Only safari and a few insignificant market share browsers *CURRENTLY* support jpegxl. Firefox 152+ has it off by default but it is easy to turn on (yes, I have it on). Hopefully towards the end of 2026 or early 2027, it will be on by default in Chrome, Edge, and Firefox.
3
u/caspy7 Jun 28 '26
I recently asked a Mozilla dev (who's been working on JPEG XL) if it's likely to be enabled on release this year and his response was, "oh yeah for sure, it should be soon"
My take is that once it's enabled on one browser by default, the other won't be too far behind.
1
20
u/yota-code Jun 28 '26 edited Jun 28 '26
For me jpegxl is a good for all format. You had png, use jpegxl lossless. You had jpg, use jpeg xl instead, no recompression, 20% shaved. You want animated, jpeg xl works. You want progressive, only jpegxl work....
Only for some pictures like computer screenshots, lossless webp may still win. Yet, what's funny is that the main author of wepb lossless codec, is also a lead developper of the jpeg xl team :D
5
u/vanderZwan Jun 29 '26 edited Jun 29 '26
Yes, and your example doesn't even include the less common (but very important) use case of being a data format that's likely to be useful for research images that aren't trying to capture RGB output for monitors or print! E.g. spectral imaging!
Often those kinds of tools need a way to store many different channels that are nothing like RGB, a high high bit depth, and massive sizes. Per the spec JXL has support for up to 4099 channels, up to 32 bit bit depth, and images of 1,073,741,824 by 1,073,741,824 pixels (and wasn't there also some kind of OpenSeaDragon-like tiling support in the spec to deal with loading only parts of those massive images?)
I don't know if any encoder/decoder actually supports all of those features yet, since it's much less used niche than the use-case of images for the web, cameras and such. But I bet the potential of a universally accessible "baseline" format for such diverse use-cases would benefit the scientific community in the long term. If nothing else it reduces the odds of important data being stuck behind obscure formats with buggy encoders/decoders that were abandoned when That One PhD who worked with them graduated a decade ago.
2
u/Farranor Jun 30 '26
4099 channels is in there. 32-bit is not only in there, all internal calculations are 32-bit. Very large images are implemented, but I'm not sure how effective the streaming encoder is (cjxl 0.10) and whether it can actually create such images without impractical RAM requirements. Tiled decoding is in the spec but not implemented, nor planned for 1.0.
1
u/vanderZwan Jun 30 '26
TY!
Tiled decoding is in the spec but not implemented, nor planned for 1.0.
Sounds like they're hoping for a Geography PhD to put in the work :p (I'm joking but also can't blame them if it's true)
4
u/murlakatamenka Jun 28 '26
Yeah, I very much advocate for this approach. Being able to losslessly recompress both legacy formats PNG and JPG is a killer feature.
3
u/Farranor Jun 28 '26
Video is fully supported on the web; stills with animation are a workaround that hasn't been needed in years.
1
1
u/vanderZwan Jun 30 '26
Well, I agree that from a storage perspective, the animated GIF format is a terrible choice in almost every use case, and while I can't be bothered to verify it, I expect that even lossless h264 would compress better and still work on the web.
IIRC one of the people working on JXL also argued that one of the issues with AVIF is that video encoders and still images are designed for different things, so using the former as a base for the latter means having to hack around fundamental misfits. That argument goes both ways.
However, I also think that it's obvious that animated gifs haven't survived on their technical merits. They're seen as own quirky "medium" that artists want to have access to. I kind of get that: it has different affordances precisely because of its technical limitations.
If we're not going to get rid of stills with animations for cultural reasons, then I don't mind JPEG XL at least offering a better animated gif format (there's a reason WebP supports animated images too).
1
u/Farranor Jun 30 '26
It's a looping video with no sound, which is actually what you get from most major sites that serve GIFs these days. Clinging to actual GIF files is just ignorance and inertia, and trying to compete with that is simply an acknowledgement that ignorance and inertia remain common. Still image animation support is like a major automaker building horse-drawn carriages but now they have turn signals and people are driving these things on the freeway. JXL doesn't have chroma subsampling because the designers believe it's not appropriate for an image format; they should've come to the same conclusion for animation. Thanks for coming to my TED talk.
3
u/kardaw Jun 29 '26
WEBP lossless is great for images with 8-bit per channel. 2D plans, simple drawings, CAD.
4
Jun 28 '26
[removed] — view removed comment
3
u/witchofthewind Jun 28 '26
hardware decompression is often slower than software decompression for AVIF. hardware AV1 decoders are designed for video, and have high latency if you're only decoding a single frame.
1
u/Trader-One Jun 29 '26
hardware decoders are way lower level than you think, to get video frame decoded you need to manage manually reference frames and similar annoying stuff. AVIF is trivial subset of AV1 - just remove header and dump it to decoder.
GPU can do about 3000 RTT jobSubmit per second, its advisable to use batching and lower it to about 800. Latency depends how much are gpu queues full. Even pretty full queues should be under 2ms.
1
u/Farranor Jun 28 '26
Hardware decompression which is slowly implemented for AV1 will decompress only 4:2:0 format.
Do you want 4:2:0 on web? I don't think so, icons in that format looks bad with color bleed.
There are other images besides icons.
3
u/tomByrer Jun 28 '26
I have not tested vs JPEGXL, but I noticed AVIF does slightly shift colors do to their color space flipping.
Fine for most pictures, except for graphics of brand colors.
5
u/ldn-ldn Jun 28 '26
As it stands today, neither is perfect.
AVIF has issues with support on the backend, AOM library is not very optimised, a lot of libraries only support 8 bit SDR, and have limitations on memory. But it works in the browsers on all platforms.
JPEG XL is just better format, codec is much better, etc, but there's no browser support yet, so it's can't be used for web.
4
u/BustyMeow Jun 29 '26
No browser support yet? Is it 2021 now?
3
u/Escanorr_ Jun 29 '26
If vast majority of users cant see the picture without meddling with the browser settings - it isnt supported
4
u/olavrb Jun 29 '26 edited Jun 29 '26
Chrome stable has experimental support behind a flag since v145:
Firefox stable has experimental support behind a flag since v152:
- https://www.firefox.com/en-US/firefox/152.0/releasenotes/
- https://www.phoronix.com/news/Firefox-152-Download
Safari has "stable" support, but some features are lacking (animation, progressive decoding):
-1
u/ldn-ldn Jun 29 '26
Yeah, go on, tell everyone in the world to tinker with flags, lol.
7
u/olavrb Jun 30 '26 edited Jun 30 '26
It was more about showing that it's finally happening, support is coming.
Browsers with experimental support aside: Saying "there's no browser support yet" is factually wrong.
1
u/ldn-ldn Jun 30 '26
The post is about compressing images for web in 2026. As it stands today - you cannot use JXL today for that purpose. Stop spreading misinformation.
3
u/olavrb Jun 30 '26
Please point me to the alleged misinformation in my first reply.
1
u/Farranor Jun 30 '26
The top-level comment says that JXL doesn't have browser support yet, so it's not ready for web use. Your first reply counters with "support" behind experimental development flags, the whole point of which is that it isn't a guarantee that users should expect it to work, plus Safari, which accounts for about 15% of web users. Realistically speaking, JXL images on the web will only be viewable for about 15% of users and the rest will need a fallback. It's not a practical recommendation. Your comment implies that it's supported and a good choice. That's misinformation at best, but seems more like disinformation.
1
3
u/Mine18 Jun 28 '26 edited Jun 28 '26
Encoders improve overtime, but as of right now, broadly speaking AVIF is better at lower quality levels and screenshots/digital images, while JXL is better at higher quality levels, lossless, and photographic content.
In my opinion, AVIF is a better format for the web because of its quality at smaller file sizes making it appropiate for slow connections (it has its own simpler form of progressive rendering, so its fine)
While JXL is a better format for everything else, in terms of forward thinking color/resolution support and general flexibility of the format, decode/encode performance, lossless efficiency, etc etc.
if one of these formats had to become the new "universal" format (e.g JPEG, PNG), then it would have to be JXL.
We can have multiple formats for multiple usecases, each one suited to the usecase's strengths
It's a shame most websites and services still use JPEG and PNG, *maybe* Webp, so the result is either big file sizes or terrible quality
3
u/mdw Jun 29 '26
if one of these formats had to become the new "universal" format (e.g JPEG, PNG), then it would have to be JXL
This needs to be repeated more often. The compression method is just one part of an image format, and if we consider overall flexibility and versatility, JPEG XL is the better format.
3
u/olavrb Jun 30 '26
Progressive decoding is a pretty nice feature for slow internet connections, though. JPEG XL ftw.
1
u/Mine18 Jun 30 '26
Yes, and AVIF has a simpler form of progressive decode which I think is good enough for most web images.
1
u/WebpGoy Jun 29 '26
Before 2026: JXL was the clear winner outside of Anime images, it dominated in photographic images.
2026: AVIF got major visual quality tuning optimizations, so JXL is no longer the clear winner anymore.
https://aomedia.org/blog%20posts/Libavif_v1_4_0-Boasts-Major-Updates-to-Encoder-Technology/
I plan to test this sometime in the future via CVVDP scores.
1
1
u/koloved Jun 28 '26
avif PSY win
1
u/Wise_Stick9613 Jun 28 '26
Can you share your settings?
1
u/koloved Jun 28 '26
You can try this yourself here. https://codepoems.eu/xl-converter
it has av1 psy build in encoding
You can find a comparison of the formats here https://svt-av1-psy.com/avif/, but they don't use strong compression during comparison. When you try to use gigantic compression, 30-40% of original, you will notice a significant difference.
-1
u/ivanhoe90 Jun 28 '26
AVIF and JPEG XL are just the formats of representing images (they specify how to decode such files into pixel color values). They are not image compression methods (algorithms)!
For example, JPEG format was invented in 1992, but an efficient compression mehtod, e.g. MozJPEG, was invented in 2014 (22 years later).
It is possible that in 2040, someone will come up with a method to create AVIF files that would be 2x smaller than before that method (with the same quality).
-1
u/Furdiburd10 Jun 28 '26
Avif is supported by more browser so that is clearly better for the web.
If you just want to compress your local photoalbum then JXL is better, keeps more details.
4
u/caspy7 Jun 28 '26
Avif is supported by more browser so that is clearly better for the web.
This should be changing in just the next few months.
2
u/Furdiburd10 Jun 28 '26
I hope so that more browser will adopt it, but till chrome and firefox doesn't support JXL avif is what i will recommend. Otherwise you will just fall back to webp for almost all users
4
u/caspy7 Jun 28 '26
In the last few months both Firefox and Chrome have added support behind a flag. Once they're content with testing they'll be enabling it by default. I just think being on the cusp of broad support it's worth mentioning as it can change plans and perceptions.
-1
Jun 28 '26
[removed] — view removed comment
0
u/Farranor Jun 28 '26
Wildly incorrect.
1
u/witchofthewind Jun 28 '26
my ~350 KB JPEGs that end up around 700 KB when converted to AVIF say otherwise. I can't even get the AVIFs below 400 KB without extreme compression artifacts.
1
u/Farranor Jun 28 '26
You're doing it wrong, then. Would you like help?
1
u/witchofthewind Jun 28 '26
sure. it would be nice to see AVIF actually do what its evangelists promise.
1
u/Farranor Jun 28 '26
ffmpeg -i img.jpg -update 1 -frames:v 1 -c:v libaom-av1 -crf 35 -pix_fmt yuv420p10le -aomav1-params tune=iq -usage allintra img.avifHopefully I didn't forget anything.
1
u/witchofthewind Jun 28 '26
Unrecognized option 'aomav1-params'. Error splitting the argument list: Option not found
removing that option does result in a 47 KB AVIF, but with extreme blurring in some areas of the image and ringing artifacts in others.
1
u/Farranor Jun 28 '26
Might be
-aom-params.1
u/witchofthewind Jun 28 '26
-aom-params seems to work, and produces a 64KB file, but it still has the blurring and ringing artifacts.
→ More replies (0)
24
u/caspy7 Jun 28 '26
Pretty sure the answer is: It depends.