AVIF vs JPEG XL in 2026: Which Next-Gen Image Format Should You Ship?

The short answer: ship AVIF in 2026, serve WebP as the fallback, and keep JPEG as the final fallback. JPEG XL is the most capable format of the three on paper, but it only displays by default in Safari, which covers roughly 15 percent of web users. Until Chrome ships JPEG XL support by default, a JPEG XL only strategy would leave about 85 percent of your visitors with a broken image. AVIF gives you most of the compression win right now, in browsers used by about 95 percent of people.

This is a genuine decision, not a fashion choice. Picking the right format can cut a page's image weight roughly in half, which shows up directly in loading speed, mobile data use, and search performance. Picking the wrong one means images that do not load at all for most of your audience. This guide compares AVIF and JPEG XL on the four things that actually decide the question: file size, browser support, encoding speed, and the special features each format brings.

What AVIF and JPEG XL actually are

AVIF (AV1 Image File Format) is built on the AV1 video codec, developed by the Alliance for Open Media, a group that includes Google, Apple, Mozilla, Microsoft, and Netflix. It arrived in 2019 and reached browsers steadily from 2020 onward: Chrome 85, Firefox 93, Safari 16, and Edge 121. In 2024 it crossed the line into "Baseline" status, meaning it is safe to treat as a standard web feature. It supports both lossy and lossless compression, transparency, animation, HDR, and wide colour gamuts.

JPEG XL (file extension .jxl) is the successor to JPEG from the Joint Photographic Experts Group, standardised in 2022. It was designed to fix everything JPEG gets wrong: it compresses better at high quality, supports HDR and wide gamuts, decodes progressively so a usable preview appears after only a fraction of the file has downloaded, and it can recompress an existing JPEG losslessly, shrinking it while keeping the exact original recoverable. On technical merit alone, many engineers consider it the best image format ever designed. Its problem was never quality. Its problem is distribution.

The browser support picture in late 2026

Browser support is the whole story here, so let us be precise. These figures come from caniuse global estimates as reported in 2026 format benchmarks, and they have barely moved all year for JPEG XL.

JPEG XL's history explains the gap. Chrome shipped it, then removed it in 2023, citing low interest. Firefox keeps it behind a flag. Safari alone ships it by default since version 17. The twist in the story came in late 2025, when a Rust based JPEG XL decoder contribution was welcomed into Chromium and landed in Chrome Canary 145 behind a flag. That reversed Google's 2022 decision in spirit, but a flag in Canary is not support in stable Chrome, and several 2026 benchmarks put realistic default Chrome support in the second half of 2026 at the earliest. Until that ships, JPEG XL remains a Safari only format for practical purposes. If your analytics show a heavily Apple audience, that 15 percent figure understates your real coverage, but for a general public site, it is the number that matters.

File sizes: how much smaller, really

Compression claims vary by test because they depend on the image and the quality setting, so treat any single number with suspicion. The honest picture comes from comparing several 2026 benchmarks at matched visual quality rather than matched quality settings, since a "quality 80" means something different in every encoder.

Two patterns show up across the benchmarks. First, AVIF wins at the low to medium bitrates that dominate ordinary web use: hero images, thumbnails, and product photos. Second, JPEG XL pulls ahead at high quality, where fine detail matters, and it can beat AVIF by roughly 20 percent there in some tests. One matched quality benchmark found AVIF about 37 percent smaller than JPEG, WebP about 22 percent smaller, and JPEG XL about 18 percent smaller on web sized images, with JPEG XL's edge appearing only at very high fidelity. Another set of real image tests found AVIF 37 to 67 percent smaller than JPEG at the same visual quality. The ranges differ, but the conclusion does not: AVIF is the smallest practical choice for most web images today, and JPEG XL's compression advantage is real but confined to cases where its support problem already rules it out.

A worked example makes the savings concrete. Take a 2400 pixel wide landscape photo saved as a JPEG at quality 80, weighing 820 KB. At the same visual quality, expect roughly these sizes: WebP around 570 KB (about 30 percent smaller), AVIF around 410 KB (about 50 percent smaller), and JPEG XL around 450 KB in a Safari side test. On a page with six such photos, switching from JPEG to AVIF takes image weight from about 4.9 MB down to about 2.5 MB. That is the difference between a page that feels instant on a mid range phone and one that visibly loads image by image. These are illustrative figures from the benchmark ranges above, not a lab measurement of one specific photo, but they match what site owners see when they convert a real gallery.

Encoding speed: the hidden cost of AVIF

AVIF has one serious drawback that file size tables hide: it is slow to encode. Depending on the encoder and settings, AVIF encoding runs roughly 5 to 20 times slower than WebP, and on large batches you feel it immediately. A build pipeline converting thousands of product photos can go from minutes to hours. JPEG XL, by contrast, was designed for speed, and at its default settings its encoder runs far faster than AVIF's while achieving comparable compression.

For most sites this is a build time problem, not a visitor problem. Decoding speed, which is what your visitors experience, is fine for both formats. The practical fixes for slow AVIF encoding are simple: encode once at build time or on upload, never on the fly per request; use a faster AVIF encoder setting for bulk jobs and reserve the slowest, highest quality setting for hero images; and cache aggressively so no image is ever encoded twice. If your pipeline genuinely cannot absorb AVIF encoding time, WebP remains a respectable fallback at 25 to 35 percent smaller than JPEG, with the fastest encoding of the three.

The features only JPEG XL has

JPEG XL deserves its reputation, and three of its features have no equivalent in AVIF. First, progressive decoding: a JPEG XL image shows a usable preview after only about 1 percent of the file has downloaded, then sharpens as the rest arrives. Neither WebP nor AVIF can do this, and for large hero images on slow connections it is a genuinely better experience. Second, lossless JPEG transcoding: JPEG XL can shrink an existing JPEG by roughly a tenth to a fifth with zero quality loss, and the exact original JPEG can be reconstructed bit for bit from the smaller file. No other format does this, and it makes JPEG XL uniquely attractive for archives. Third, it handles very high fidelity, HDR, and wide gamut content with less banding than its rivals at the top end.

AVIF's own strengths are less exotic but more useful today: near universal browser support, the best compression at everyday quality, HDR and wide gamut support, transparency in both lossy and lossless modes, and animation support. It also has one practical advantage that matters for site owners: it is the format Google's own tooling recommends. PageSpeed Insights flags oversized JPEGs and points toward AVIF and WebP, which means choosing AVIF aligns your site with the advice your performance audits are already giving you.

How to serve images in 2026: the practical stack

You do not have to pick one format for everyone. The HTML picture element lets the browser choose the first format it supports, so you serve the best format each visitor can actually display. This is the stack the benchmarks converge on:

Serve AVIF first, WebP second, and JPEG as the final fallback. In code, that looks like a picture element with an AVIF source, then a WebP source, then a plain img tag pointing at the JPEG. Browsers download only the first format they support, so nobody downloads two copies. Modern Chrome, Firefox, Edge, and Safari all get AVIF. Slightly older browsers get WebP. Everything else, including email clients and very old software, gets JPEG. When Chrome eventually ships JPEG XL by default, you add it as the first source without changing anything else, which is exactly why this structure is worth adopting now rather than hard coding a single format.

A migration checklist keeps the switch safe. Keep your lossless masters (PNG or TIFF) and never treat a converted AVIF as your only copy. Convert in bulk at build time, not per request. Keep the JPEG fallback in place permanently, because email clients, social scrapers, and older software still expect it. Test on a real older Safari and an older Android browser, not just your own phone, because the 5 percent without AVIF support is concentrated there. And measure after you switch: compare total image bytes and Largest Contentful Paint before and after, since a format change that does not move those numbers was not worth doing.

For converting your existing images, start with the photos that carry the most weight. Our JPG to AVIF converter handles the headline case, photo to AVIF, entirely in your browser, and our PNG to WebP converter covers the fallback format. If your images are also oversized in dimensions, resize first with our Image Resizer, then convert, then compress with our Image Compressor. Resizing a 4000 pixel upload down to the 1200 pixels it is actually displayed at often saves more bytes than any format change, and the two wins stack.

When JPEG XL is the right choice anyway

There are real cases for JPEG XL today, and pretending otherwise would be dishonest. If you run a photography archive, a stock library, or a print workflow, JPEG XL's lossless JPEG transcoding and high fidelity compression make it the best archival format available, regardless of browser support, because your users download files rather than viewing them inline. If your audience is overwhelmingly Apple, Safari 17+ coverage may already be high enough to serve JPEG XL as an extra first source in your picture element, with AVIF behind it. And if you are building a pipeline you expect to run for years, adding JPEG XL output now costs little and means you are ready the day Chrome enables it by default. What you should not do is ship JPEG XL as your only web format, or drop your JPEG fallback to make room for it.

The decision, in one paragraph: AVIF is the format to ship in 2026 because it combines the best everyday compression with support in about 95 percent of browsers. WebP is the fallback that covers almost everyone else. JPEG is the universal safety net that never goes away. JPEG XL is the format to watch, to archive in, and to add as a first source the moment Chrome ships it by default, which the Canary 145 decoder suggests could happen in the second half of 2026. The winner of this race was never going to be the best codec in the abstract. It is the one that is both good and actually supported, and in 2026 that is AVIF.

For the wider picture, our image format comparison for 2026 covers JPG, PNG, WebP, AVIF, and SVG side by side, and our guide to compressing images without losing quality walks through the quality settings that matter once you have picked a format. If you are migrating an existing site rather than starting fresh, the complete WebP guide covers the fallback format in depth.