WebP vs AVIF

Both take a modern video codec and use it on a single frame. WebP is a still from VP8, published by Google in 2010. AVIF is a still from AV1, published by the Alliance for Open Media in 2019 — a consortium including Google, Netflix, Amazon, Mozilla and Apple, formed specifically to build a codec nobody had to pay for.

Nine years of codec research separate them, and it shows in the file sizes. Both are royalty-free, which is the property that made either of them possible and which distinguishes both from HEIC, technically AVIF’s closest relative.

On photographic content the advantage is clear: typically twenty to thirty per cent below a WebP of comparable quality, and more at aggressive settings. It also handles the cases WebP struggles with — smooth gradients, night skies, subtle skin tones — with much less banding, because it is not limited to eight bits per channel.

On flat interface graphics, icons, screenshots and line art the picture reverses. Those compress extremely well already, and AVIF frequently produces a larger file than WebP for the same image. This site’s own measured comparison shows exactly that: AVIF twice as small on a photograph and noticeably larger on flat colour with hard edges. Convert five representative images of your own before believing any general claim, including this one.

AVIF encoding is expensive — often an order of magnitude slower than WebP for the same image, because AV1 searches much harder for structure it can describe compactly. A large photograph can take several seconds on a fast machine.

For a static site built once, that is irrelevant: the cost is paid on your computer and every visitor benefits. For a platform processing user uploads in real time, it is a capacity question with a bill attached, and it is the main reason services adopted WebP years before AVIF and still generate both.

Both support transparency with a real alpha channel and both support animation, so neither is limited to still opaque images.

AVIF adds what a modern display can show: ten and twelve bits per channel, wide colour gamuts, and high dynamic range. WebP is capped at eight bits in a standard gamut, which is fine for the great majority of web imagery and is a genuine limitation for photography intended to look its best on a good screen.

One historical footnote worth knowing: WebP’s lossless mode is excellent and widely used, while AVIF’s exists and is less well supported by tooling. For a lossless asset, WebP is usually still the more practical choice.

Both are read by every current browser. WebP has a longer tail of support in non-browser software — image viewers, editors, some content systems — simply by being older, and neither can be relied on outside a browser. Email a WebP or an AVIF and you have the same problem.

So the choice is not about compatibility between these two. It is about what the images are, what the encoding costs, and whether the pipeline can produce two formats instead of one.

Serve both. A picture element with an AVIF source first, a WebP source second and a JPG or PNG fallback lets every browser take the best it can read, and it is the arrangement that needs no detection and no maintenance.

If only one, choose by content. A photography portfolio, an e-commerce catalogue, a travel site: AVIF, where the saving is largest and the banding improvement is visible. An application interface, a documentation site, anything mostly screenshots and diagrams: WebP, which will often produce smaller files and always encode faster.

Both are lossy at their default settings, and both are delivery formats. Converting an existing JPG to either re-encodes an already lossy image and compounds the damage — generate from the master where one exists.

And keep the masters. The reason this comparison exists is that a better format arrived nine years after the last one, and the same will happen again. An asset library kept losslessly can produce whatever comes next; one that has been converted in place can only produce copies of a copy.