WebP used to be the easy answer to "what's the smallest format I can safely use?" These days that's outdated on two counts: AVIF, quietly gaining support since 2020, now beats WebP on pure compression in most real-world tests, and the old reason people avoided it — creating one was awkward — mostly doesn't apply anymore either.

But "AVIF is smaller" is too blunt a summary. There are specific, predictable cases where WebP still produces the better file, and knowing which is which saves more bytes than always reaching for the newest format.

Why AVIF compresses better

WebP is built on VP8, a video codec from 2010. AVIF is built on AV1, a video codec finished a decade later — and video codecs are where image compression research actually happens, since even a 1% improvement matters enormously at streaming scale. AV1 brought meaningfully better tools, and AVIF inherits all of them.

Three differences do most of the work:

Flexible block sizes. VP8 works in a fairly rigid grid. AV1 can split the image into blocks ranging from tiny to very large, and choose per region. A flat expanse of sky gets described by one large block instead of hundreds of small ones; a face full of detail gets subdivided as finely as it needs. Matching the block size to the content is most of where the savings come from.

Better prediction. Before storing anything, both codecs guess what a block will look like based on its neighbours, then store only the error in that guess. AV1 has many more ways to make that guess — including directional modes that follow edges at a wide range of angles — so the error it has to store is smaller.

Higher bit depth. AVIF encodes at 10 or 12 bits per channel internally even when the source is 8-bit. That sounds like it should make files bigger, and instead it reduces banding: the encoder has finer gradations to work with when approximating a subtle gradient, so skies and shadows step less visibly at the same file size.

In practice this lands in the 20–30% range in AVIF's favour for photographs, with the largest, most detailed images seeing the biggest gains. AVIF also supports HDR and wide-gamut colour, which WebP cannot represent at all — not something most people need day to day, but decisive for photography-heavy sites.

Where WebP still wins

This is the part usually left out.

Very small images. AVIF carries more structural overhead per file, and below a certain size that overhead stops paying for itself. Encoding the same flat icon at a fixed quality, we measured WebP smaller at 40 pixels a side and below — 388 bytes against AVIF's 427 at 32 px, and 352 against 417 at 40 px — with AVIF pulling ahead from 48 px up. Plain PNG beat both at those sizes, since a flat graphic is exactly what lossless compression is good at. So the honest cut-off is favicons and very small avatars, not thumbnails: by 64 px AVIF is already comfortably in front.

Lossless graphics. WebP's lossless mode is a genuinely excellent, purpose-built design for flat colour and sharp edges. AVIF's lossless mode is comparatively an afterthought, and on screenshots, logos and line art it frequently loses to both WebP lossless and plain PNG. If you need pixel-exact output, WebP is usually the better modern choice.

Encoding time. AVIF is dramatically slower to produce — often several times slower than WebP for the same image, because all that flexibility means searching a much larger space of possible encodings. For one image it's imperceptible. For a folder of four hundred, it's the difference between a coffee break and an afternoon.

Very high quality settings. As you push quality towards the maximum, AVIF's advantage narrows and can invert. Near-lossless is not the regime it was tuned for.

So the honest rule is narrower than "AVIF wins": AVIF wins on photographs at normal quality settings, at reasonable dimensions. That happens to describe most images on most websites, which is why it's a good default — but it isn't universal.

The catch that isn't really a catch anymore

What kept AVIF from being the obvious default was this: every modern browser can display an AVIF file without any trouble, but creating one directly in a browser only ever worked reliably in Chrome and Edge. Firefox and Safari never shipped a native AVIF encoder, so tools that rely on the browser's own canvas to do the conversion simply produce a different result there, or grey out AVIF as an option entirely.

That's a real limitation, but it's a limitation of that specific approach, not of AVIF itself. img-compress doesn't rely on the browser's built-in encoder — it runs its own AVIF encoder, compiled to WebAssembly, the same way it processes every other format. The result: AVIF conversion that works identically in Chrome, Firefox, Safari, or Edge, entirely on your device, with nothing uploaded anywhere.

What about browser support?

For viewing, both are done. Every browser still receiving updates displays WebP and AVIF without a fallback. WebP has the longer history, so it also works in a longer tail of abandoned software, but if your audience is on anything maintained, this is no longer a real distinction.

Where it does still matter is outside the browser: upload forms, older desktop applications, print workflows and content management systems accept WebP noticeably more often than AVIF, simply because it has been around longer. If something rejects your file, that's usually the reason — and converting to JPG or PNG is the fix, not switching between the two modern formats.

The quality numbers aren't comparable

This trips up almost everyone who tries to compare the two fairly. Quality 80 in WebP and quality 80 in AVIF are not the same setting. They're inputs to entirely different encoders, and each one maps its scale onto its own internal decisions. Setting both to 80 and comparing the resulting file sizes tells you very little, because you're almost certainly comparing two different visual qualities.

AVIF's scale in particular tends to run "hotter": a given number often produces a visibly better image than the same number in WebP, which makes AVIF's file look unfairly large in a naive comparison. If you want a real answer, match the two by appearance — adjust until they look equivalent to you at the size you'll actually display them — and only then compare the bytes.

The same caveat applies to any benchmark you read, including the 20–30% figure above. Those numbers come from studies that carefully equalise perceptual quality first. A blog post that sets both sliders to 75 and reports the difference is measuring nothing.

Animation

Both formats handle animation, and both demolish GIF — animated WebP and AVIF are routinely a fraction of the size at far better colour depth, since GIF is stuck at 256 colours.

Between the two, animated WebP is the safer pick today. Support for animated AVIF is thinner than support for still AVIF, and a few players and preview tools that happily display a static AVIF will show only the first frame of an animated one. The compression advantage is real, but so is the risk of a silently broken animation, and for short loops the absolute saving is small.

How to test it on your own images

Benchmarks average over image sets that probably look nothing like yours. Ten minutes with your own files beats any article, including this one:

Pick three or four images that genuinely represent your work — a detailed photo, a flat graphic, and something in between.
Convert each to both formats, adjusting quality until the two versions look the same to you at display size.
Compare the file sizes, and note which content types show a real gap and which are a wash.

You'll usually find the answer is content-dependent in exactly the way this article describes: a large gap on photos, a much narrower one on simple graphics, and a reversal on anything small.

Deciding, in practice

Photos for the web, and you're not encoding hundreds at once → AVIF. This is the case it's best at, and it's the most common one.
Screenshots, logos, line art, anything with text → WebP, lossless. AVIF is the wrong tool here.
Favicons and tiny avatars, roughly 40 pixels and under → WebP, or PNG for flat graphics. Below that size AVIF's overhead outweighs its efficiency; from 48 px up it no longer does.
A very large batch where turnaround matters → WebP. The size difference rarely justifies multiplying the encoding time by several hundred.
Archiving photos where storage cost dominates → AVIF, and let it take as long as it takes.
Something rejected your upload → the answer is JPG or PNG, not the other modern format.

Trying it yourself

img-compress's JPG to AVIF converter handles photos, the PNG to AVIF converter works directly from screenshots and graphics, and the WebP to AVIF converter starts from a WebP file if you want to squeeze out what's left — all three run entirely in your browser. Need to go the other way because something you're uploading to hasn't caught up with AVIF yet? The AVIF to JPG and AVIF to PNG converters handle that just as directly, and if the goal is broader acceptance rather than maximum compatibility, the AVIF to WebP converter is a smaller step back that still keeps transparency. Nothing gets uploaded to a server, and it works identically no matter which browser you're using. If you're deciding between formats more broadly, WebP vs JPG vs PNG vs AVIF covers the full picture.

AVIF vs WebP: Why AVIF Compresses Better