AVIF, the format succeeding JPEG

AVIF builds on the AV1 video codec to compress still images, which generally lets it reach visual quality comparable to JPEG at a significantly smaller file size. It also handles transparency and high dynamic range — two things JPEG simply cannot do. Here is what that means in practice, and where the format still costs you something.

Where the size savings come from

JPEG was standardised in 1992 and its compression reflects the constraints of that era. AVIF borrows the intra-frame coding tools of AV1, a codec designed three decades later for video, where squeezing every frame matters enormously. It can predict blocks from their neighbours in far more ways and adapt block sizes to the content, so flat areas cost almost nothing while detailed regions keep their budget.

Commonly cited comparisons put AVIF somewhere around 20 to 50 percent smaller than JPEG at matched visual quality, and meaningfully ahead of WebP as well. Treat those numbers as an order of magnitude rather than a guarantee: the gap depends heavily on the image. Photographs with smooth gradients and skies benefit the most; small images and noisy textures benefit least, and a very small icon can even come out larger because of container overhead.

What AVIF does that JPEG can't

Three capabilities matter beyond raw file size. AVIF carries a real alpha channel, so a logo or product cut-out keeps its transparent background — with JPEG you would be forced back to PNG. It stores more than 8 bits per colour channel, which supports HDR and wide colour gamuts and, more mundanely, avoids the banding you sometimes see across a JPEG sunset. And it supports animation, making it a credible replacement for animated GIF at a fraction of the weight.

The trade-offs worth knowing

Encoding is slow — noticeably slower than JPEG or WebP. For a single image nobody notices; for a batch of several hundred it is the difference between seconds and minutes, so it is worth starting a large conversion and letting it run. Decoding is fast enough that readers will not perceive it.

The second trade-off is tooling. Plenty of desktop software, older content management systems and image editors still do not open AVIF, so it is a poor choice for a file you need to hand to someone else. Keep AVIF for images you serve, and JPG for images you send.

Browser support and how to keep a fallback

Current versions of Chrome, Firefox, Safari and Edge all decode AVIF, so the majority of live traffic is covered. That still leaves older installations and unusual clients, and the fix costs three lines of markup. The picture element lets the browser pick the first format it understands:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="…" width="1200" height="800">
</picture>

Browsers evaluate the sources in order and stop at the first supported type, falling back to the plain img if none match. Keeping width and height on the image reserves its space during loading, which protects your layout shift score.

So should you switch?

For images you publish on a site or app, AVIF is a sound default: it is the strongest compressor of the three widely supported web formats, and the fallback pattern above removes the compatibility risk. If your largest image is also the page's Largest Contentful Paint element, the saving lands directly on a metric Google measures.

Stay with JPG for files that leave your control, and reach for WebP when you want most of the benefit with broader tooling support and much faster encoding. One habit is worth more than the format choice itself: resize images to the dimensions they are actually displayed at before compressing them. That single step usually saves more than any codec upgrade.