awxkee

JPEG XL vs AVIF: Which Image Format Should You Actually Ship? 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: - JPEG XL vs AVIF for web use-cases, Jake Archibald, October 2026 - image-codec-bench, the benchmarking harness and methodology - jixel, the second JPEG XL encoder - The case against JXL, the AVIF-side counter-argument

JPEG XL vs AVIF na web: comparei 24 fotos na mesma qualidade percebida; o resultado muda conforme a qualidade-alvo O Jake Archibald publicou esta semana uma comparação longa de JPEG XL e AVIF para uso na web, e hoje o Jyrki Alakuijala, co-designer do JPEG XL, escreveu no X uma posição diferente em parte. Rodei um teste pequeno antes de postar e o resultado ajuda a entender por que os dois podem ter razão. Contexto - Segundo o caniuse, o JPEG XL tem suporte no Chrome 155+ e no Firefox 158+, e parcial no Safari. O artigo do Jake parte disso: "JPEG XL has now landed in all major browsers". - Ele comparou AVIF (avifenc 1.4.2), JPEG XL por dois encoders (libjxl 0.12.0 e o jixel 0.4.2, mais novo) e WebP, medindo qualidade com SSIMULACRA2 e ColorVideoVDP. O que o Jake diz - Fotos com perda: o AVIF quase sempre gera arquivos menores. No esforço padrão, o melhor JPEG XL fica tipicamente 15% a 25% maior; no esforço máximo, 6% a 20%. - Screenshots, ilustrações e transparência: vantagem maior do AVIF. Sem perda: JPEG XL vence com folga. - Decode: JPEG XL leva 2 a 3x mais tempo em qualidade média, diferença que cai em qualidade muito alta. - JPEG existente: o JPEG XL reduz de 9% a 20% sem perda. - Recomendação dele: AVIF 4:4:4 como padrão, no maior esforço viável; olhar o JPEG XL via jixel quando o AVIF sair grande demais. E não usar 4:2:0 como padrão. O que o Jyrki diz - "AVIF can work well at quality 60 and below." Acima de 85, que ele chama de qualidade mediana da internet, o JPEG XL "works far more reliably". O que eu conferi - 24 fotos do conjunto Kodak (768x512), q de 20 a 99, 1.539 encodes, esforço padrão: avifenc -s 6 -y 444, cjxl -e 7 e jixel com a velocidade padrão. Tamanho interpolado na mesma nota SSIMULACRA2, mediana por imagem; "melhor JPEG XL" é o menor entre libjxl e jixel. - SSIMULACRA2 50 a 85: o AVIF ganhou por pouco. O melhor JPEG XL saiu de 0,7% a 7,6% maior (mediana). - SSIMULACRA2 90, que o Jake classifica como visualmente sem perda: o JPEG XL ficou menor em 19 de 24 fotos, mediana de 10,6% a menos. - O mesmo q 80 deu nota mediana 84 no AVIF, 77 no libjxl e 64 no jixel. Em q 90: 89, 86 e 82. - JPEG q85 convertido para JPEG XL sem perda: mediana de 14,1% menor, e as 24 voltaram idênticas byte a byte (sha256). O que isso é (e o que não é) - É um indício de que a resposta depende da qualidade-alvo, coerente com o que o próprio Jake mostra num exemplo ("JPEG XL catches up at very high quality"). - Não é um contra-benchmark. Usei só o esforço padrão, fotos pequenas e antigas (scans de filme), uma métrica e uma máquina. No conjunto do Jake, com imagens de 1598 px, a diferença a favor do AVIF foi maior. - O "quality 85/90" do Jyrki é configuração de encoder, não nota SSIMULACRA2. Não dá para ligar uma coisa à outra direto, e o item do q 80 mostra o tamanho do problema. Onde eu fico Para foto em qualidade média ou alta, o AVIF 4:4:4 continua sendo um padrão razoável. Se o site serve imagem muito perto do original, ou se o acervo já é JPEG, vale medir JPEG XL. Em qualquer caso, a comparação tem que ser na mesma nota de uma métrica, não no mesmo número de quality. Links - Artigo do Jake: jakearchibald.com - Jyrki no X: x.com - caniuse: caniuse.com - Encoders: AOMediaCodec/libavif · libjxl/libjxl · awxkee/jixel Perguntas 1. Em que qualidade vocês servem imagem hoje, e como chegaram nesse número? 2. Alguém já mede com SSIMULACRA2 (ou outra métrica) no pipeline, ou o quality é escolhido no olho? 3. Para quem tem acervo grande em JPEG: a conversão sem perda para JPEG XL já está no radar?

>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 another Rust JXL decoder separate from jxl-rs named jixel.[0] [0] awxkee/jixel