AVIF still beats JPEG XL for most web images, Jake Archibald's benchmarks find

JPEG XL is now supported in every major browser, closing the years-long gap that kept it out of most developers' image pipelines. To take stock, developer Jake Archibald — whose comparison recently reached the Hacker News front page — benchmarked JPEG XL against AVIF across photos, screenshots, transparency, HDR, progressive rendering and lossless use, and concluded that AVIF remains the better default for most web images today.

Photos: AVIF keeps the size lead

For lossy photographs, AVIF nearly always delivers the smaller file, according to Archibald. At default encoder effort, the best JPEG XL result is typically 15–25% larger than the equivalent AVIF; at maximum effort the gap narrows to 6–20%. Outliers exist where JPEG XL matches or beats AVIF, so for a particular hero image he suggests trying both. Encoder choice also matters: jixel, a newer JPEG XL encoder, usually produces smaller files than the reference libjxl, except when an image has detailed transparency. On his F1 test photo, the best JPEG XL output at default effort came in 14–17% larger than AVIF.

Screenshots, illustrations and transparency fall further behind

The difference widens for non-photographic content. Equivalent JPEG XL files for screenshots and illustrations were 30–90% larger at default effort and 20–70% larger at maximum effort. Archibald adds that lossy AVIF handles this content well, so lossless formats are unnecessary unless bit-exact output is genuinely required. Transparency is weaker still: libjxl output runs 31–44% larger at default effort and 61–70% larger at maximum, while jixel encodes transparency losslessly by default, yielding files two to three times the size of AVIF's.

Encoding speed, decoding speed and settings

AVIF is generally quicker to encode and uses less memory once file size is taken into account. jixel encodes faster than AVIF but produces noticeably larger files, so AVIF wins on balance. Decoding favours AVIF too: JPEG XL typically takes two to three times as long at medium quality, though the gap narrows at very high quality, where Chrome can occasionally decode JPEG XL faster. Higher effort settings pay off for AVIF and jixel, but not for libjxl, whose slow modes cost far more time and memory for negligible gains — sometimes producing larger files than the default. Archibald also advises against AVIF's 4:2:0 chroma mode as a default, since it rarely reduces file size and makes higher quality harder to reach.

Progressive rendering and HDR

jixel recently added early progressive previews, which add little or no cost at its slowest setting but inflate files by about 12% at its default setting. Chrome and Firefox display these previews; Safari decodes the final image without showing them. AVIF has also gained progressive rendering — Chrome-only for now, with Firefox work under way — and while it is more complex to set up than JPEG XL's approach, it offers more control over what the preview looks like, usually smaller files and much faster decoding. On HDR, JPEG XL's gain map support exists in the format specification but browser decoders don't implement it and encoding remains experimental, which Archibald flags as a major practical drawback. For HDR content without gain maps, his two quality metrics disagreed substantially, but both found JPEG XL produced smaller files.

Where JPEG XL clearly wins

Two categories favour JPEG XL. For lossless compression, lossless WebP is 9–17% larger for photos and lossless AVIF is 30–120% larger. And JPEG XL can recompress existing JPEGs 9–20% smaller with no additional loss, decoding as fast or faster than the original except on small images. Archibald caveats both points: lossless is rarely the right choice for web delivery, and jixel's higher effort levels can produce files that decode too slowly. He also argues against animated image formats altogether.

The recommendation

Archibald's current default is AVIF at 4:4:4 with the highest effort level he can tolerate, switching to JPEG XL via jixel only when AVIF produces an unusually large file. Both ecosystems have improved rapidly, so he expects the ranking could change. He also warns that much of the surrounding discussion is misinformation — which AI assistants will happily repeat — and advises developers to benchmark their own images. The AVIF community contends JPEG XL is technically limited by comparison; Archibald sidesteps that debate by testing only current implementations. His benchmarks ran on a 2024 MacBook Pro with an M4 Pro chip, using the latest codec releases (avifenc 1.4.2, libjxl 0.12.0, jixel 0.4.2 and cwebp 1.6.0), images 1598 pixels wide, and the SSIMULACRA2 perceptual quality metric.

Why it matters

Image payload remains one of the biggest levers on web performance, and JPEG XL's arrival in all major browsers gives developers a genuine second modern format rather than an AVIF monoculture. Archibald's numbers show the practical decision is empirical rather than ideological: AVIF wins most web use cases today, but JPEG XL has real niches in lossless work and in shrinking large libraries of existing JPEGs without quality loss. With both codec ecosystems improving quickly, the sensible workflow is measurement — encode with both, compare on your own images, and retest as encoders evolve.