WebP vs AVIF: which format wins, and where

Both formats are video codecs wearing a hat

WebP wraps VP8's keyframe encoder in a RIFF container, with a completely separate algorithm behind its lossless mode. AVIF takes a single AV1 intra frame and puts it in a HEIF container, which is ISOBMFF, the same box structure MP4 uses. Almost every difference between them traces back to that ancestry: AV1 is the newer and stronger codec, and it is also the far more expensive one to run.

That matters because the choice is rarely "which compresses better". It is a choice between compression, encode cost, browser reach and how your particular images behave. Those four pull in different directions depending on whether you are shipping product photography or UI screenshots.

Start with the hard limits

Before any quality argument, look at what each format simply cannot do. These are properties of the bitstream, not encoder settings you can talk your way around.

That 16,383 pixel ceiling exists because VP8 stores width and height in 14 bits each. Stitched panoramas, long scrolling illustrations and large scanned documents reach it sooner than people expect. The 4:2:0 restriction is subtler and bites more often: chroma is sampled at half resolution on both axes, so red text on a white background and thin coloured rules soften as a structural consequence of the format. Lossless WebP sidesteps this entirely because it works directly on RGBA.

How much smaller, and whose number is it

Most percentages quoted in format arguments have no source attached. Here are the ones that do.

• Google's WebP compression study measured WebP files at 25-34% smaller than JPEG at the same SSIM index; the WebP FAQ rounds that to roughly 30% on average.
• The same source puts lossless WebP at 26% smaller than PNG.
• The web.dev article on AVIF reports savings of more than 50% against JPEG, while stating plainly that the real figure depends on content, encoder settings and quality target.
• MDN, citing CTRL Blog's comparison, gives a median of 50% compression for AVIF versus 30% for WebP over the same set of JPEG sources.

Read those together and the honest conclusion is that AVIF's lead over WebP is real but much narrower than either format's lead over JPEG, and it swings hard with content. Noisy, textured photography is where AV1's tooling pays off. Flat colour, sharp edges and screenshots close the gap and can reverse it. Rather than trusting a percentage, produce both files from the same source and compare: JPEG to AVIF and JPEG to WebP take about as long as reading this paragraph.

Five places AVIF loses

Small images

An AVIF writes a chain of container boxes before the first pixel: ftyp, meta, iloc, iinf and a property block describing size and codec configuration. That fixed cost is invisible on a 3000-pixel photograph and substantial on a 32 by 32 badge, which is why AVIF routinely loses to PNG or lossless WebP at icon sizes. Anything that could be vector art belongs in SVG anyway, and the SVG tools will tell you quickly whether the file is worth keeping as vector.

Encoding cost

Producing AVIF is far more expensive than producing WebP. web.dev documents a 6.5x reduction in CPU and a 5x reduction in memory for still image encoding between libaom 2.0.0 and 3.1.0, measured at speed=6, cq-level=18 on 8.1 megapixel images. The point is not that AVIF is cheap now; it is that even after a 6.5x improvement this remains the heavy option. The encoder speed setting is a direct trade: slower settings buy smaller files. In a pipeline that converts user uploads on request, that time becomes queue depth. In a pre-built catalogue it costs nothing at serve time.

No progressive rendering

MDN states it directly: AVIF does not support progressive rendering in browsers, so the file must download completely before anything appears. On small files nobody notices. On a large above-the-fold hero over a slow connection, a progressive JPEG resolving from blurry to sharp can feel better than an empty box that fills in one step.

Screenshots, diagrams and flat colour

Interface captures, charts and text-heavy images have few colours and many hard edges, which is the worst case for every lossy encoder: you get ringing along the edges. The right answer here is usually lossless WebP or a well-optimised PNG, and switching such content to lossy AVIF without comparing first is how screenshots end up with unreadable small text. PNG to WebP in lossless mode makes that comparison a one-step job.

Browser reach

MDN lists first AVIF support as Chrome 85, Opera 71, Firefox 93, Safari 16.1 and Edge 121. That last entry is the interesting one, arriving years after the others. WebP's table is far more relaxed: Chrome 23, Edge 18, Firefox 65 and Safari 14. In practice this means AVIF still needs a fallback path, while WebP can reasonably be served on its own to most audiences.

Where WebP runs out of room

WebP is the safe choice today, but its ceiling is low. Being 8-bit only means it cannot carry the wide gamut and high dynamic range data that current phone cameras produce, so those photos get squeezed into sRGB and smooth sky gradients start banding. There is no 4:4:4 option in lossy mode, so the moment you need fine coloured detail preserved you have to jump to lossless and watch the file size climb. Anyone preparing iPhone photos for the web meets this ceiling quickly; HEIC to JPG works as an intermediate step, but AVIF is the better destination if you want to keep what the sensor captured.

Serving both without making a mess

The mechanism is the picture element: an image/avif source first, then image/webp, with a JPEG or PNG in the closing img as the fallback. The browser takes the first type it recognises. The server-side alternative is to inspect the Accept request header and choose, in which case you must send Vary: Accept or intermediate caches will hand the wrong bytes to the wrong client.

Count the cost honestly. Three formats mean three times the storage, three times the cache keys, three encodes per image and three files to invalidate on every update. For a site with a few dozen images, picking one format and tuning it properly beats running a three-format pipeline badly.

Rules that hold up

• Large photographs, over about 100 kB as JPEG: try AVIF, the saving usually justifies the encode.
• Thumbnails and small photos: WebP, since AVIF's container overhead eats the gain.
• Screenshots, UI captures, line art: lossless WebP or an optimised PNG.
• Icons, logos, simple graphics: SVG.
• HDR or wide gamut photography: AVIF, because WebP cannot represent the data at all.
• If you can only ship one: WebP, for reach and encode cost.

Whichever you land on, a format swap is not a substitute for compression discipline. The biggest wins still come from resizing to the dimensions you actually display and choosing quality by measurement rather than by feel, which is a topic of its own: compressing images without visible loss. For batch work the image compressor handles the common cases, and when you need to go back the other way, AVIF to PNG and WebP to PNG cover it.