WebP vs AVIF: which image format should you actually use?

Let us get the answer out of the way: serve AVIF to browsers that accept it and WebP to everything else, decided per request, and stop thinking about it. Content negotiation has made this a solved problem, and no site should be manually choosing one format for all its visitors in 2026.

The more useful discussion is why AVIF wins where it wins, why WebP is still doing most of the work in practice, and why the format argument is a distraction from a much bigger saving that most sites are leaving on the table. We will get to that last part, because it is the one that actually matters.

How they compare

Rough relative size at similar perceived quality. Individual images vary a lot; the ranking does not.

Where AVIF genuinely pulls ahead

AVIF is derived from the AV1 video codec, and it inherits the tools that come with a decade of extra research. That shows most on photographic content with gradients — skies, skin tones, dark scenes, anything with smooth transitions. Where JPEG and WebP start banding and blocking at low bitrates, AVIF degrades gracefully. If you run a photography portfolio or sell anything visual, that difference is worth having.

Where WebP is still the better tool

Two situations. First, small images — icons, thumbnails, UI sprites. AVIF carries more container overhead, and on a 3 KB thumbnail that overhead can make the AVIF version larger than the WebP one. Always compare rather than assuming.

Second, anything you need to encode quickly or frequently. AVIF encoding is expensive — commonly five to ten times slower than WebP at comparable quality settings. For a build-time asset pipeline that is irrelevant. For user-uploaded images being processed on demand, it is a real cost, which is why on-the-fly conversion systems typically cache aggressively.

The saving that dwarfs the format choice

Here is the part that makes the WebP-versus-AVIF debate look small.

Go and look at the images on your site — the actual files, not what the page displays. On a very large number of sites, a photo displayed in a 400-pixel-wide card is a 3000-pixel-wide original, straight from someone's phone or a stock library. That image is roughly 56 times the pixel data being displayed.

Converting that 3000px JPEG to AVIF might take it from 1.8 MB to 900 KB. Resizing it to the 800px it actually needs on a high-DPI screen takes it to about 60 KB. The resize is worth more than the format by an order of magnitude, and no amount of clever encoding rescues you from sending pixels nobody will ever see.

• Resize first, then choose a format. In that order. The second decision only matters once the first is made.
• Serve at roughly 2× the CSS display size for high-DPI screens, and no more. Beyond 2× the difference is not visible.
• Use responsive srcset so a phone does not download the desktop-sized version at all.
• Set width and height attributes. Free, and it prevents layout shift while the image loads.
• Never lazy-load your LCP image. It is the one image that must arrive immediately.

Doing it without a build step

Every browser sends an Accept header listing the image formats it can handle. An edge that reads that header can convert and resize on the fly: you upload one high-quality original, and each visitor receives the smallest format their browser supports, at the dimensions their layout needs, cached after the first request so the conversion cost is paid once.

That is worth doing not because it is clever but because it is the only approach that survives contact with reality. Manual export pipelines work until someone uploads a 4000px product photo through the CMS on a Friday afternoon, and then they quietly stop working and nobody notices for six months.

So the honest summary: the format question has an automatic answer, and the question worth your attention is whether you are shipping images ten times larger than the space they are displayed in. Check one product photo. You may not like what you find.