For years the answer to "which modern image format should I use?" was easy. AVIF, full stop. JPEG XL was the promising codec Google helped design and then declined to ship in Chrome, and the whole conversation got poisoned by conspiracy theories about why.
That changed this month. JPEG XL has now landed in all major browsers, including Chrome. The format war everyone assumed was over just reopened, and the first serious piece of post-launch evidence is a monster benchmark by Jake Archibald, who has been writing AVIF comparisons since 2020. He ran four encoders across photos, screenshots, illustrations, transparency, HDR, and lossless cases, measuring file size, encode time, memory, and decode speed.
A disclosure before the numbers: I have not run these benchmarks myself. Every figure below comes from Archibald's published results, with the methodology and raw data linked in his post. What I have added is the part he intentionally skips: a decision matrix you can apply to your own image pipeline, and the commands to verify it with your own images.
The headline result: AVIF still wins most lossy photos
For lossy photos, AVIF almost always produces smaller files. At default encoder effort, the best JPEG XL version was typically 15 to 25 percent larger than the equivalent AVIF at the same perceptual quality. At maximum effort the gap narrows to roughly 6 to 20 percent. On a typical F1 test photo at high quality (SSIMULACRA2 score of 70), AVIF hit 41.4 kB while libjxl needed 58.4 kB and the newer jixel encoder 46.6 kB.
The encoder matters more than most people realize. The interesting twist in this benchmark is not just JPEG XL vs AVIF, it is libjxl vs jixel, a newer second JPEG XL encoder. jixel usually beats libjxl on file size, except on images with detailed transparency, where it falls back to lossless alpha encoding and balloons.
AVIF is also faster and lighter on balance. jixel encodes faster than AVIF, but its files are bigger, so to actually match AVIF's output it needs its slowest setting, which took 18 to 27 times longer in the benchmark. Decode time matters even more for your users: JPEG XL typically takes 2 to 3 times as long to decode as AVIF at medium quality, and that cost lands on every single page view, on every device.
Where JPEG XL genuinely beats AVIF
If the story were only lossy photos, this article would be two paragraphs long. It is not, and here the benchmark delivers real surprises.
Lossless compression is a JPEG XL blowout. For lossless photos, lossless WebP came out 9 to 17 percent larger and lossless AVIF 30 to 120 percent larger than JPEG XL. If you store or serve bit-exact images, the calculus flips completely.
Recompressing existing JPEGs is JPEG XL's killer feature. JPEG XL can make existing JPEG files 9 to 20 percent smaller without any additional quality loss, and decode them as fast or faster, because it can wrap the original JPEG coefficients instead of re-encoding pixels. For anyone sitting on years of legacy JPEG archives, that is free bandwidth on images you never have to regenerate.
Progressive loading is nearly free in JPEG XL. jixel recently added progressive encoding, and at its slowest settings the preview support costs little or nothing in file size. Firefox and Chrome both render progressive JPEG XL previews; Safari downloads the full image before showing anything. Meanwhile AVIF turned out to support progressive rendering too, currently Chrome-only, with more control over the preview and faster decode. This space is moving on both sides.
Where AVIF is not even close
Three categories ended decisively.
Screenshots and illustrations: lossy AVIF was 30 to 90 percent smaller than JPEG XL at default effort, and 20 to 70 percent smaller at maximum effort. And you do not need lossless formats for screenshots; lossy AVIF handles them well unless you genuinely need pixel-exact output.
Transparency: libjxl files were 31 to 44 percent larger at default effort and 61 to 70 percent larger at maximum. jixel was worse, because it always encodes alpha losslessly, landing 2 to 3 times the size of AVIF.
HDR: JPEG XL lacks browser support for gain maps, which is how AVIF carries HDR brightness metadata. The format supports them on paper, but browser decoders do not, and the encoding tooling is experimental.
One more finding worth internalizing: animated image formats lose to video, every time. In Archibald's clip test, animated AVIF hit 725 kB where animated JPEG XL needed 2.17 MB for the same quality score, and both lose to a plain <video muted autoplay loop>.
The decode cost lands on your users, not your build server
It is tempting to read "JPEG XL encodes fine with jixel" and conclude the formats are equivalent and you can pick either. The encode step is the cheap part. Encoding happens once per image on your build server. Decoding happens on every visitor's device, every time the image loads, including cache revalidations and bfcache misses.
JPEG XL typically takes 2 to 3 times as long to decode as AVIF at medium quality, and the gap only narrows at very high quality settings, where Chrome can sometimes decode JPEG XL faster. On a flagship phone nobody notices either way. On a three-year-old mid-range Android device on a congested network, decode time is part of your Largest Contentful Paint, and LCP is part of how your pages rank and convert. A format that wins file size by 10 percent but doubles decode time can easily be a net loss for the user-perceived speed of an image-heavy page.
The benchmark measured decode in real browsers, Firefox, Chrome, and Safari, on the actual decoded images, which is the right way to do it. Treat any codec comparison that only reports encode numbers with suspicion.
One reassuring finding: quality settings behave predictably
If you automate encoding in CI, you depend on a quality flag meaning roughly the same thing across images. The benchmark checked this explicitly, and the result is that quality settings are reliable for all four encoders: with a single quality setting, output quality varies somewhat between images, but all encoders vary in the same direction and in ways that seem reasonable. You will not get a 95 kB surprise out of a pipeline configured for 50 kB targets. That makes a build-time AVIF pass, with a JPEG XL fallback attempt only for outlier files, a safe thing to automate.
The 4:2:0 trap
A subtle but expensive finding: AVIF's 4:2:0 mode, which halves color resolution, should not be your default. It rarely reduces file size in practice, and it makes higher quality targets harder to reach. Many tutorials and CI pipelines still use it because it encodes and decodes faster. The benchmark's advice is to stick with 4:4:4 unless you have time to compare both per image. If your current pipeline was configured years ago, this single flag may be costing you quality for zero savings.
Your decision matrix
Here is the whole benchmark compressed into one checklist you can save:
- Default for photos on the web: AVIF at 4:4:4, with the highest encoder effort you are willing to wait for.
- When AVIF produces an unusually large file: try JPEG XL via jixel on that image; there are real outliers where it wins.
- Screenshots, diagrams, illustrations: lossy AVIF. Drop the lossless habit unless you need bit-exact output.
- Images with transparency: AVIF, by a wide margin.
- Legacy JPEG archives: JPEG XL lossless recompression, 9 to 20 percent smaller, no extra loss.
- Bit-exact lossless storage: JPEG XL, the clear winner over lossless WebP and lossless AVIF.
- HDR imagery: AVIF, because of gain map support.
- Animated images: use video. Both animated formats are worse and this benchmark shows by how much.
Verify it with your own images
Both authors of the benchmark and the counter-arguments agree on one thing: codec discourse is full of misinformation, and your AI assistant will happily repeat it. Test with your own images.
Archibald released his benchmarking harness on GitHub, using avifenc 1.4.2, libjxl 0.12.0, jixel 0.4.2, and cwebp 1.6.0. For a quick manual check with libavif's tools:
# AVIF at 4:4:4, quality 50
avifenc --yuv 444 -q 50 -j all photo.jpg photo.avif
# JPEG XL with libjxl, distance 1.0 (roughly high quality), effort 7
cjxl -d 1.0 -e 7 photo.jpg photo.jxl
Then compare file sizes at visually identical quality. His benchmark targeted SSIMULACRA2 scores, a perceptual quality metric from the JPEG XL team, so comparing a 41 kB AVIF against a 58 kB JPEG XL at the same score is the fair way to do it, not at matching quality flags.
In your HTML, both formats work inside a <picture> element so older browsers fall back gracefully:
<picture>
<source srcset="photo.avif" type="image/avif" />
<source srcset="photo.jxl" type="image/jxl" />
<img src="photo.jpg" alt="Product photo" width="1598" height="1065" />
</picture>
The benchmark encoded test images at 1598 pixels wide, twice the maximum display width, which keeps them sharp on high density screens. That is a reasonable target width for content images too.
So which one should you ship?
For web use cases, as of October 2026: default to AVIF 4:4:4 at high effort, and reach for JPEG XL when you have a JPEG archive to shrink or a lossless case, or when AVIF underperforms on a specific image. Both encoders have improved massively in recent months, so this recommendation has an expiration date, and the honest move is to re-run the numbers on your own assets before a big migration.
What I find genuinely interesting here is the meta-lesson. JPEG XL was written off for three years because of a browser politics fight, and a second independent implementation showing up changed the benchmarks more than any codec committee decision could. Competition between encoders is now real, and whichever format "wins," the files your users download keep getting smaller.
I write about web performance, developer tooling, and AI infrastructure every week. Subscribe, it is free.
Do you serve AVIF in production today, or are you still on WebP with a <picture> fallback chain? Have you measured what a format switch actually saved you?
Sources:
Top comments (0)