WebP vs AVIF vs JPEG at Equal Quality: 20 Photos Measured

The question: if you encode the same photograph as JPEG, WebP and AVIF and ask each file to look equally good, how many bytes does each format need? Quality sliders cannot answer that, because “quality 75” means something different in every encoder. So we fixed the visual quality instead and measured the file size needed to reach it.

Short answer from our run: at an SSIMULACRA2 score of 70 (“high quality”), AVIF needed fewer bytes than MozJPEG for all 20 photographs, with a median saving of 29.4 %. WebP, surprisingly, did not beat MozJPEG on photographs at that target: it was smaller for only 9 of the 20 photos, and its median file was 2.6 % larger. On screenshots the picture changed completely, and WebP was 41.7 % smaller than JPEG.

What we tested

The corpus is the lab’s fixed set of 20 CC0 and public-domain photographs from Wikimedia Commons: landscapes, a night city scene, food, a macro flower, fur, feathers, a street sign, dunes, an interior and more (credits on the image credits page). Each photo was rotated upright, converted to sRGB and resized so its long edge is 1600 pixels, then saved as a lossless PNG reference. We also ran four real screenshots of this website through the same pipeline.

• JPEG: MozJPEG through sharp 0.35.5, quality 30 to 95 (10 steps), default 4:2:0 chroma subsampling.
• WebP: libwebp 1.6.0 through sharp, quality 30 to 95 (10 steps), effort 4.
• AVIF: libaom 3.15.1 through sharp, quality 20 to 90 (11 steps), effort 4. Note that sharp encodes AVIF with full-resolution 4:4:4 chroma by default; the effect of that choice is tested separately below.

That is 1,036 encoded files. Every file was decoded and scored against its reference with SSIMULACRA2, DSSIM and SSIM, as described in the testing methodology. For each photo and format we then interpolated the file size at which the score crosses 70.

Results: bytes needed for the same quality

Across the 20 photographs, the median file size at SSIMULACRA2 70 was 157.2 KB for JPEG, 176.0 KB for WebP and 113.5 KB for AVIF. Medians hide the spread, so the table lists every photo.

AVIF’s advantage ranged from 4.8 % (a small win) to 66.6 % (a third of the JPEG size). The biggest AVIF wins were on images with large smooth or soft areas: the macro flower, the coffee cup and the market scene. The smallest wins were on the images full of fine, high-contrast detail, such as the street sign, the waterfall and the stone texture, where every format needs a lot of bytes.

The crops above are taken at 100 % from the bird-feather photo, using the ladder step closest to a score of 70 in each format. At this size the three files are hard to tell apart, which is the point of the threshold. Looking closely, the WebP file (quality 80, score 68.4) smooths the finest speckles of the feather slightly, while the JPEG and AVIF files stay closer to the reference; none of the three shows obvious blocking at this size. The AVIF file is the smallest of the three by a wide margin: 199 KB against 317 KB for the JPEG.

What surprised us: the metrics disagree about WebP

If you use the older SSIM metric with a 0.95 target instead, WebP looks much better: it was smaller than JPEG for all 17 photos that reached that target inside the ladder, with a median saving of 22.2 %. AVIF’s median saving grew to 36.2 %. At a stricter SSIMULACRA2 target of 80, WebP’s median came out 1.9 % smaller than JPEG, which is effectively a tie.

Why the gap? SSIM here only looks at brightness (luma), while SSIMULACRA2 also scores colour and is more sensitive to the smoothing WebP applies to fine texture. WebP’s lossy mode always stores colour at quarter resolution (4:2:0), and MozJPEG’s quantisation tables are well tuned for photographs. Depending on the metric you trust, “WebP is 25–35 % smaller than JPEG” is either roughly right or not true at all for photographs like these. That is why our guides always name the metric next to the percentage.

Screenshots behave differently

On the four screenshots of this site, both modern formats won clearly at SSIMULACRA2 70: the median JPEG needed 80.9 KB, WebP 49.3 KB and AVIF 21.4 KB. That is a 41.7 % saving for WebP and 70.3 % for AVIF. Flat colour, sharp text and large empty areas are exactly what JPEG handles worst. If your site’s images are mostly interface captures or diagrams, also read our lossless screenshot test, because for that kind of image a lossless format is often the better choice.

Is AVIF’s win only because of 4:4:4 chroma?

sharp encodes AVIF with full-resolution colour (4:4:4) by default, while our JPEG and WebP files used the usual 4:2:0. To check that this did not give AVIF an unfair advantage, we re-encoded every image as AVIF 4:2:0 over the whole quality ladder and repeated the equal-quality comparison. At SSIMULACRA2 70, AVIF 4:2:0 was still smaller than MozJPEG for all 20 photos, with a median saving of 28.9 % (against 29.4 % with 4:4:4). For photographs, the two AVIF modes needed almost the same bytes for the same quality (a median difference of 1.75 %). The full chroma results, including JPEG and WebP, are in our chroma subsampling test.

The cost: encoding time

AVIF’s savings are not free. On our bench, the median time to encode one 1600-pixel photo was 117 ms for MozJPEG, 144 ms for WebP and 541 ms for AVIF at effort 4. That matters little for a site that encodes each image once at upload, but it matters for on-the-fly image services. Our AVIF effort test measures how the speed setting changes both numbers.

Practical conclusion

• For photographs, AVIF was the only format that reliably beat a well-tuned JPEG at equal perceived quality in our run, by roughly a third at the median.
• Do not assume WebP is automatically a large win over MozJPEG for photographs. Measure it on your own images with a perceptual metric, not only the quality number.
• For screenshots and flat graphics, both WebP and AVIF save 40–70 % over JPEG.
• Serve AVIF with a fallback (<picture> with WebP or JPEG) and check that your server sends the image/avif content type. Our own WordPress host did not, as we found in the AVIF upload test.

Repeat this test on your own images

You can run the same comparison on your own photos with free tools. Resize a few representative originals to the width you publish, save them as lossless PNG, then encode each one at several settings:

cwebp -q 75 -m 4 photo.png -o photo-q75.webp
avifenc -q 50 -s 6 photo.png photo-q50.avif
# JPEG with MozJPEG (cjpeg from the mozjpeg package)
cjpeg -quality 80 -outfile photo-q80.jpg photo.png

Decode every output back to PNG (dwebp, avifdec, or any image editor) and score it against the source with ssimulacra2 photo.png decoded.png. For each format, note the smallest file that reaches the score you consider acceptable; that is a fairer comparison than the same quality number in every encoder. Our own scripts (run_codecs.py and analyze_codecs.py in the archive on the image credits page) automate exactly this, including the interpolation between ladder steps.

Limitations

Twenty photographs at 1600 pixels, one encoder per format, one speed setting and three metrics. Different encoders (for example cwebp with other presets, or rav1e and SVT-AV1 for AVIF) and other image sizes will move the numbers. SSIMULACRA2 70 is a strict but not perfect proxy for “looks the same”; the 100 % crops are there so you can judge for yourself. Browser decoding speed was not measured here.

Data and files

Download codecs.csv (1036 rows, 105.3 KB) · Download equal-quality.csv (28 rows, 2.0 KB) · Method and versions: testing methodology. Photographs: image credits.