alt Hacker NewsJPEG XL vs. AVIF for web use-cases
Comments
Having lived through the MP3 era and experienced the many years/decades? that it took for experts across fields to come together and figure out LAME and the bag of parameters that ultimately made it better than most audio formats around it, I would lean towards waiting this one out, and not take any announcement of a "winner" as gospel. We've yet to see the codecs mature and refine for some time.
I also remember the big claims about WebP's superiority, which ended-up in practice, at equivalent file-size, mostly trading away some of the JPEG artifacts that we all know for some unusual new ones.
I don't think there's a large-enough margin in this space that a new format could chew into to make the general public care: image compression seems like a solved problem overall. The second best thing is to come-up with a format that can make the content producers not have to care either, i.e. be the best in class or close-enough in a variety of use-cases (lossy, lossless, fast, animated, hdr, progressive, …). My naive impression was that jxl is mostly interesting in that regard.
> For screenshots and illustrations, AVIF is much better than JPEG XL.
Have you tried encoding with JPEG XL’s modular mode? By default, libjxl only uses it for lossless and I haven’t tried with jixel, but in my experience, it often handles clean edges and smooth surfaces (the likes of which you might see in digital art) better.
> I'm a little nervous about this, because discourse around JPEG XL can get a little… weird.
As someone who’s been rooting for JPEG XL for years now, I also find the discourse a little upsetting. When first introduced, the format was very competitive with AVIF and steadily improving, until Google decided to single-handedly halt web adoption (de facto, because market share). No careful evaluation presented, no solid argumentation given.
My understanding is that the future of the format became uncertain at that point, because web adoption is regarded as crucial and no one wants to go all-in on a codec that may not end up filling the universal role it was designed for. Of course, AV1 encoders kept seeing lots of interest and improvement in the meantime, because everyone was already all-in on AV1 for video.
And now, when JPEG XL has finally painstakingly clawed its way back onto its original trajectory, now there are comparisons popping up showing how AVIF actually compresses better. People end up quoting them around social media, painting the picture that JPEG XL turned out to be the inferior format after all. It hasn’t, it just got a massive handicap.
Not that it’s a problem with your article. It’s informative, you compare the current state of available encoders for a specific use case, and you mention how they’re still evolving. It just sucks that we can’t really do a fair comparison of the formats at this point, yet that’s exactly what people will end up doing anyway, and it’ll really suck if it ends up hurting JPEG XL even more than Google already has.
I think people are really forgetting that JXL's encoders are bad right now. For instance, in TFA Jake presents
- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) [1] (or 43kB if you need it to work with jxl-rs [2])
- The cat illustration w/ lossless JXL at 255.3kB, when with a better encoder you can get it down to 178kB (30% smaller) [3]
[1] https://www.linolevan.com/05-screenshot.jxl
AVIF is fantastic format and I use it in my production applications. Spent quite a bit of time looking to the best settings (at least for up to 2k images) and for anyone interested in converting images to AVIF, here's what I've found to work the best for creating the smallest size (10x+ smaller) while still retaining good quality and even supports PNG transparency:
ffmpeg -i {input_file} -filter_complex "[0:v]format=pix_fmts=yuva444p,split[color][alpha];[alpha]alphaextract[alpha_chan]" -map "[color]" -map "[alpha_chan]" -c:v libaom-av1 -crf 25 -cpu-used 3 -still-picture 1 -aom-params "sharpness=2:enable-chroma-deltaq=1:arnr-strength=0" -color_range pc -colorspace bt709 -color_primaries bt709 -color_trc bt709 {output_file}That F1 image is, in my mind, proof of exactly what is wrong with AVIF. If you look closely the beautiful highlights on the car have been erased and replaced with something plausible. Once you see it you can't unsee it and it boggles my mind that people are still using it as an example.
Granted, AVIF performs impressively for, say, a huge hero image for a blog where you're out to create an overall impression and people aren't going to look at it closely. It does not impress me when I am compressing photos I took with my mirrorless and I expect them to look like photos taken with a mirrorless and not cell phone snaps.
The benchmark[1] (HN discussion [2]) I read from about 2.5 years ago came to roughly the opposite conclusion. JPEG XL dominated practically all other image formats on compressed size and encoding time.
Superficially, that benchmark and this one seem to be taking similar measurements. They both measure encoded size versus encoding time versus perceptual quality metrics, although they present the data on plots with different axes. I haven't tried to reproduce the results of either, but I have no reason to doubt either benchmark.
I wonder what accounts for the difference. Maybe the libavif encoder got a lot better in the last 2.5 years. The older benchmark uses libjxl v0.10.0 and libavif v1.0.3, while the newer one uses libjxl v0.12.0 and libavif v1.4.2. Or maybe it's the set of images used. The older benchmarks aggregates results for small test sets of images, while the newer benchmark tests individual images. The newer benchmark does find an image where libjxl wins on file size (the weasel), but it still loses on encoding time, whereas in the older benchmark libjxl almost always won on both. Or maybe it's the hardware (M3 Pro vs. M4 Pro).
[1]: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
On macOS, I wanted to be able to paste HDR HEIC screenshots straight into GitHub in Safari and have them get converted automatically to these HDR-capable formats. Normally, when you switch Screenshot.app to HDR, paste to GitHub stops working.
I put together this Hammerspoon spoon with a few brew libraries and some inline Swift code.
You paste twice quickly to trigger it, and you can iterate formats with a keystroke. https://gist.github.com/thadk/8b178aa93dafcab92ca579825f8191...
I've been using AVIF on my blog for a few years. My blog's image corpus is almost entirely videogame screenshots, and I keep the original PNGs so I can re-encode if better encoders release. Despite playing around with JPEGXL every year or so, AVIF images usually looked better (if only a little) at the same file size (vs JPEGXL).
After reading this article, there's something to point to prove I'm not going crazy.
>Animated image formats are dumb and animated JPEG XL is no exception. Video formats are better at video. They're built for it. They're optimised for it. Not just in terms of encoding, but also in terms of playback.
This is something I've felt doesn't get enough attention when comparing JXL and AVIF. AVIF can be the replacement for GIF.
><video muted autoplay> is right there.
>No, I'm not adding a demo. I don't want it on my server. Use video formats for video.
I'm not sure if "Use video formats for video" is saying to use AVIF over JXL or saying to use AV1 over AVIF. If the latter, GIF-like animations have a different enough user expectation that it makes sense to have it as something different from regular videos. Even <video muted autoplay> doesn't encode the full expected behavior because GIFs are not expected to have controls like pause, play and scrub. And even if you hide the controls users will expect similar behavior when opening it in an image viewer or in a new tab. Images do not have controls so they fit better as an image, although maybe they need their own category.
Also, I didn't realize how good AVIF was at progressive rendering. I don't think I knew it could do that at all. I think AVIF is the clear winner for the web, although it is still nice to have JXL for lossless. Somehow I feel that AVIF still hasn't gained as much usage as it should, especially now that it is supported almost everywhere. I think I see more webp than AVIF, and JPEG is still everywhere. Maybe now that JXL is out, developers will take another look? AVIF is supported by 96.35%-98.83% of browsers according to caniuse whereas webp is 97.18%-99.68% and JPEG is 97.28%-99.78%.
I also didn't know there was a Rust JXL encoder named jixel.[0]
Unfortunately for the comparison-focused blog post the comparison widgets is pretty bad - you can't quickly compare 2 reference pictures (original vs AVIF or original vs JXL) at different scalings like here https://web.archive.org/web/20200915201019/https://afontenot...
(also like the BPP size metric that is picture size-independent)
Wish that widget with improvements (that allows comparison of 3 pics with 3 buttons: original/codec1/codec2) were the widespread standard (also, "hold" is a rather unergonomic action)
Otherwise, seems like AVIF has had impressive gains in both speed and quality, wonder whether JXL could catch up
I think that near lossless, progressive JPEG XL would work well, once compression algorithms improve. I am _so_ tired of trying to zoom in on a product picture (eg to see what buttons are on a remote or just to read fine print) on E-Stores, only to realize that I need to open in new tab and remove some query paramaters from the URL because they think that people are using 3G but with a computer with a fast CPU (to decode AVIF).
I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?
JPEG transcoding is one of the neatest features of JXL; there is so much existing jpeg out there. Eventually that may be unnecessary, but it's looking like this could already save a significant amount of space for photo archive backups for example.
I've found AVIF to be very effective at screenshots with lossy compression.
Text has lots of edges, hard transitions between bright and dark areas. So text requires lots of high-frequency detail, and JPEG adds a lot ringing as it bounces off all those lines and curves.
AVIF seems to follow contours, so it does a good job with line art.
Otherwise, it's hard to beat the Mozilla JPEG encoder.
JPEG XL can represent lossless images that exceed the limits of human vision. I don't expect it to replace FITS for astronomical images, but the future is weird.
(Super huge thanks to Jake Archibald for the SVGOMG web app. Which is also fantastic for line art.
https://jakearchibald.github.io/svgomg/
Squoosh is a web app front end to various image encoders
)
The question now is how much of AVIF's advantage comes from the encoder compared to the image format itself. If it is the encoder, does JPEG XL even stand a chance of catching up? AVIF will certainly receive further improvements, albeit at a diminishing rate.
AVIF/AV1 has patent trolls targeting it, an issue JPEGXL doesn't have, yet.
Every single webpage I've seen with webp / avif images also had autoplaying videos, intrusive ads, and megabytes of JS. I don't think jxl will change that... What's the point of introducing new image formats that are poorly supported and take longer to encode/decode if you're going to cancel out the space savings anyway?
https://jakearchibald.com/2026/jpeg-xl-vs-avif/#lossy---scre...
In full screen mode, the "hold for lossless" version "Firefox help"/"Submit feedback" are not underlined. In inline mode they are. Both modes seem to render a scaled down version of the image, which seems to cause these problems.
Great article!
Overall I am getting that AVIF is better on the web...unless Lossless is needed, in that case better take JPEGXL.
I don't get the hype. AVIF is marginally better than WebP which is marginally better than JPG. AVIF is also free, and since it's literally the I-frame of an AV1 stream, it can be decoded directly on the GPU, meaning you don't have to store the decoded picture in memory.
JPEG XL can't be decoded in such a way, and tons of people still use JPG.
4:2:0 chroma subsampling might be useful for compatibility. So, sticking with 4:4:4 might or might not be ideal. There are codecs such as H.264, where using 4:4:4 substantially reduces compatibility. Though, there are others like JPEG where it seems fine. Perhaps there are AV1 hardware decoders that only support the AV1 main profile? For the web, there is the HTML picture element where an avif image can be automatically selected by supported browsers and images of other codecs can be used as fallbacks, but maybe it would display wrong and not fall back if avif is supported but 4:4:4 isn't?
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video. You can convert an AV1 MP4 to AVIF and back losslessly - it's just a container change. That's why it performs so much better, because it's built for motion.
So, is animated AVIF only keyframes / p-frames, where each frame is independent from the other? I was under that impression, uncertain if there are any other capabilities it might have (like only updating part of the canvas when only parts change, like GIF supports)
I'm glad Jake's run the numbers — but do make sure you validate your own use-case rather than just following them. My personal experience has been somewhat different, but also my use-case appears to be pretty different so that's OK.
That said, I last benchmarked over a year ago, maybe I should re-evaluate. My experience was that AVIF was too slow for on-the-fly encoding, while JXL was absolutely fine and JPEGLI was also pretty useful.
A little while ago, I chucked together a comparison game on image file formats (incl a stab at av2 images), encoders, parameters to back out preferences relative to ssimulacra2 and butteraugli: https://aadhar.sh/pixel-peeper
It does seem like AVIFs win on small images, and JXL gives you progressive rendering, easy upgradability on JPEGs, and better lossless and high bitrate images.
> The interesting detail of animated AVIF is that it supports transparency, whereas AV1 video doesn't
Amazing.
Impressive. How can we use AVIF from Java? I have a Java application that relies on ImageMagick, which seems to use libheif for AVIF rather than libavif (avifenc).
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video.
What optimizations are being added? I thought it was basically the exact same codec, but different packaging and usually some adjustment to how the encoder is tuned.
I don't have any real use cases for jxl or avif or any other modern format b/c I rarely host images but all these articles are always so interesting to me. And at the end of it, I'm left wondering, is there ever going to be a single winner here?
Are inline AV1 as well supported by browsers as animated AVIF?
Jake's interest in F1 hasn't waned, which is good to see. I am presuming that picture of an Alpine/Renault at Goodwood is his 18Mb photo, but I could be wrong. Neither has his interest im image compression waned, which is also good to see. But why the move from Google to Firefox?
I am still on webp, thinking that I am on the bleeding edge in a world where artworkers are obsessed with pixels with JPG/PNG as the only formats they know, which is an advance on GIF.
Every browser advertises what formats it will accept and if it is in 'data-saving, low bandwidth mode', so I just configure the CDN to keep the names the same '.jpg' but to send the bestest format for the situation/browser, whether that be webp or AVIF, fetching super-high resolution files from the origin server, outputting them in 'retina' resolution with none of those 'picture' elements referencing half a dozen 'responsive' sizes.
In this way nobody has to care what image format is being served, and if it is deemed that everything is way too compressed, the CDN can be flushed of the cached images, quality increased, and cache rebuilt.
It looks like I will need to update my server configuration to use JPEG XL in the usual five years' time, given the lack of any revolutionary benefit.
1. How long does size, encode time and resize take compared to good old jpeg?
2. Is it possible to encode AVIF with hardware acceleration?
To be honest it's starting to sound like Google were right and adding JPEG XL support was a mistake.
I really hope that some day Firefox supports HDR AVIF images
Ah, Chrome ships JXL when we already have a better codec for the web!
It'd be interesting to scale this up to a lot of images - and have users blind A/B test, like the LLM Arena on Huggingface which helped filter out "benchmaxxing" vs actual intelligence & utility. Because 1) images can be so diverse* and 2) an intrinsic tradeoff might exist between general efficiency and out-of-distribution robustness.
It's hard to rigorously judge a codec from a handful images, especially given the large impact they would have (with a widely adopted codec encoding bazillions of images in the coming years).
* There are many intricate details that go into codecs and visual perception. For instance, our sensitivity to visual errors are dependent on colors (all of hue, saturation, and brightness), spatial frequency of artifacts, local contrast and texture presence, et cetera.
And like OP mentioned, perceptual error metrics (including SSIMULACRA2) aren't perfectly representative of human-evaluated visual quality. For instance, libjxl deliberately makes choices that hurt SSIMU2 scores, but improve human-rated quality.
Some days ago we had a similar discussion here.
For me personally, AVIF is still better, for various reasons (not solely file size compression ratio as such, though this is my number one go-to objective; browser support is also useful but to me is not so important as it is).
I am keeping a close eye on JPEG-XL, but right now I am quite settled on .avif. All my local collection is in .avif, when before it was a mixture of .jpg, .png and a few animated .gifs. From my findings a few years ago, avif is superior to jpg, png and gifs on pretty much everything it matters. On very high compression, though, I also noticed artefacts, but we had that even more so with jpg, and for 1:1 comparable file size, avif beats jpg with both eyes closed.
By the way, great article. I hope he can do another review, based on that blog entry, in, say 3 years. Would be interesting to see how avif and jpeg-xl have improved. In all likelihood I will still keep on using avif, but if jpeg-xl is a real winner in some areas, I may use it. (Lossless is one area where jpeg-xl excels, but I don't need to store satellite data; I want to store old family pictures in an efficient manner, and here it seems avif is better.)
What good is a really small file size if small but significant fraction of the people who view the page see nothing at all? I loaded this page and I can read the text and see the plots but none of the example images display.
AVIF is a lifesaver for animation with separate transparency layers so the transparency can change position frame by frame. The only other alternative is WebM which has Safari limitations.
Most of these images are not at 100%. Use large images and show 100% crops everywhere.
I think one overlooked aspect is that AVIF is container based. Meaning that once sites support, when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.
To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.
What? Stick to simple PNG. It is simple, runtime and SDK, beyond good enough and has 16bits per color component support (which webp does not have).
[flagged]
[flagged]
[dead]
[flagged]
> libjxl's maximum effort is very slow. It produces files 2–7% smaller than its default for photos, and ~25% smaller for the screenshot and illustration, but takes 9–46 seconds, which is 50–180x as long as its default. jixel gets the same results in a couple of seconds.
libjxl's slow speed at efforts >7 is primarily due to an iterative evaluation-optimization loop of a perceptual error metric called Butteraugli (by tuning quantization weights). This, as well as some other computations in libjxl encoding, happen to be data-parallel and run faster on GPUs than multicore CPUs.
In case anyone is interested, I've been working on a GPU-accelerated libjxl port (supporting CUDA and Metal for now) that makes this much faster, closer to libjxl's normal speeds: https://github.com/yunho-c/gjxl - geared for encoding a large batch images into JPEG XL. It's also faster by around 2.9x at normal effort (7).