The line you will read everywhere is that AVIF is roughly 20 to 30 percent smaller than WebP. It is repeated in framework docs, in CDN marketing and in every image optimisation post of the last three years.
So I swapped the encoder on eight gallery images, kept the quality number exactly where it was, and measured. Seven of the nine quality settings produced bigger files. Across the whole run AVIF wrote 17.12 percent more bytes than WebP.
The saving is real. It is just not where the slider is.
Eight PNG source images from this gallery, each resized to 1024 pixels wide with Lanczos, then encoded twice at each of nine quality settings: 40, 50, 60, 70, 75, 80, 85, 90 and 95.
WebP with method=6, AVIF with speed=4, both through Pillow 12.3. Every encoded file is decoded back to RGB and scored against the original with SSIM over 11x11 Gaussian windows, sigma 1.5, the standard Wang et al. formulation, on the luma channel.
method=6
speed=4
144 encodes, 72 paired comparisons. No cherry picking, no per image tuning.
AVIF wins at 40 and 50. From quality 60 upward it loses every single row, worst at 75 where it writes a third more bytes.
Anyone who runs a bulk conversion by pointing the same quality number at a different encoder, which is what most conversion scripts do, ships a heavier gallery and reports a saving.
The SSIM columns are the answer and they are the reason the size column is not a failure.
AVIF scores higher than WebP at every quality number in the table. At 80 the gap is 0.98853 against 0.97456, which is not a rounding difference. AVIF at quality 80 is producing a visibly closer reconstruction than WebP at quality 80.
The two encoders are not disagreeing about compression. They are disagreeing about what the number 80 means. AVIF treats it as a higher fidelity target, so it spends more bytes to reach it, and the extra bytes are buying something.
Which means the whole comparison above is meaningless as a codec test. It is a test of two different quality targets that happen to share a scale from 1 to 100.
Here is the honest version. For each image, take the SSIM that WebP achieves at quality 80, then find the cheapest AVIF file that reaches at least that score.
There it is. 30.76 percent smaller at matched picture quality, which is squarely inside the 20 to 30 percent everybody quotes, and slightly better than it.
Note where the quality numbers landed. AVIF 60 replaces WebP 80 on seven of eight images, and AVIF 50 replaces it on the eighth. That is a twenty point offset between the two scales, and it is the single most useful number on this page for anybody writing a conversion script.
Bandwidth is not the only budget.
Six and a half times. On a gallery of a few hundred images that is the difference between a conversion that runs while you make coffee and one that runs overnight. It is a build cost rather than a serving cost, so it is paid once, but it is not nothing and nobody mentions it.
AVIF also gets slower as quality rises: 1.523 seconds at quality 40 against 4.137 at 95. WebP moves from 0.285 to 0.548 across the same range.
One. Do not carry the quality number across. If your gallery is WebP at 80, the equivalent AVIF is 60, not 80. Copying the number is how a migration ends up shipping more bytes.
Two. Pick the target metric, then find the number per image. The offset was 20 points on seven images and 30 on the eighth. A single global setting leaves savings on the table on the easy images and undershoots on the hard ones.
Three. Budget the encode time before you commit. 6.5 times is measured at AVIF speed 4. Faster speed settings exist and they trade back some of the size advantage, which is a third measurement nobody in this argument has run either.
Four. Keep WebP in the picture. A 30 percent saving is worth having and it is not worth breaking a working pipeline for. WebP is supported everywhere, encodes in a sixth of the time, and the gap here is a third of a file rather than an order of magnitude.
Eight images, all AI generated art from one gallery, all portrait subjects with smooth gradients and soft backgrounds. That is exactly the content AVIF handles best, so if anything this test flatters it.
SSIM is one metric and it is not the eye. It rewards structural agreement and it under weights the specific artefacts each codec produces, which are different artefacts. Two files at identical SSIM can look different, and AVIF and WebP fail in different ways when pushed.
One encoder version, one machine, one set of settings. Nothing here is a claim about AVIF and WebP in general.
What does generalise is the method. Do not compare two encoders at the same slider position. Compare them at the same measured quality, and let the slider land wherever it has to. Yesterday that argument applied to WebP against JPEG. It applies harder here, because the two scales are twenty points apart.