# AVIF vs WebP vs JPEG compared

Canonical: https://rendobar.com/blog/avif-webp-jpeg-measured/
Author: Abdelrahman Essawy
Published: 2026-08-20
Updated: 2026-08-20

---

## Key takeaways

- AVIF produced 13.4 KB against JPEG q8's 23.4 KB and WebP q80's 24.6 KB, so 43% and 45% smaller respectively.
- PNG produced 264.3 KB, which is 19.7x the AVIF. Lossless is not a delivery format.
- AVIF took 428 ms against JPEG's 124 ms. That is 3.5x, and on a single image it is still irrelevant.
- WebP at quality 80 and JPEG at q8 landed within 5% of each other, so WebP's win over JPEG is smaller than its reputation suggests at comparable settings.
- Each format ran at its own conventional quality setting, because these scales are not interchangeable.

The AVIF-versus-WebP argument is usually conducted with numbers from someone
else's test set. Here is one frame, four formats, measured.

Short version. AVIF won decisively on size, by **43% against JPEG** and **45%
against WebP**, and paid for it with 3.5x the encode time, which on a single
image nobody will notice.

## AVIF is not a marginal win

| Format | Size | vs AVIF |
|---|---:|---:|
| AVIF | **13.4 KB** | — |
| JPEG q8 | 23.4 KB | +75% |
| WebP q80 | 24.6 KB | +84% |
| JPEG q3 | 39.2 KB | +193% |
| PNG | 264.3 KB | +1,872% |

Getting the same picture out in **13.4 KB** instead of **23.4 KB** is the kind of
difference that shows up in a Core Web Vitals score, not just in a spreadsheet.
On an image-heavy page it is most of your LCP budget.

The catch is not encode time. It is that AVIF decode support, while now broad,
is still worse than JPEG's, and JPEG's is universal. The standard answer is a
`<picture>` element with AVIF first and a JPEG fallback, which means encoding
both and serving whichever the browser admits to supporting.

## WebP's reputation is better than its numbers

**24.6 KB** against JPEG's **23.4 KB**. At these settings WebP was marginally
*larger*.

That is not the received wisdom, and it deserves a caveat: WebP quality 80 and
JPEG q8 are different scales, so this is one point on two different curves rather
than a matched-quality comparison. What it does show is that WebP's advantage
over a well-tuned JPEG is far smaller than the "30% smaller than JPEG" claim
that follows it around, and that claim usually compares against a *badly tuned*
JPEG.

If you already ship WebP, AVIF is the upgrade worth making. If you ship JPEG,
going to WebP alone is not obviously worth the pipeline change.

## PNG is not a delivery format

**264.3 KB**, nearly twenty times the AVIF, for a photographic frame.

PNG is lossless, so it stores every sensor artefact and every compression
artefact already baked into the source. That is exactly right for screenshots,
diagrams and anything with flat colour and hard edges, and exactly wrong for
photography. It is on this list because people reach for it by default and then
wonder why the page is slow.

## The encode times are all irrelevant

**124 ms** for JPEG, **168 ms** for WebP, **428 ms** for AVIF, **197 ms** for PNG.

AVIF is 3.5x the slowest of the lossy options and it is still under half a
second for a single frame. Unless you are encoding at genuinely high volume, this
column should not influence the decision at all. Pick on output size and decode
support.

The one place it matters: AVIF encoding scales badly with resolution and with
effort settings. At `-cpu-used 8` we are on the fast end. Pushing quality further
gets slow quickly, which is why AVIF is usually generated once at upload rather
than on the fly.

## About the quality settings

JPEG `-q:v 3` and `-q:v 8`, WebP `-quality 80`, AVIF `-crf 30`. Each is that
format's own conventional setting and **none of them mean the same thing**.

Note also that JPEG's scale runs the opposite way to everything else: `-q:v 2`
is best and 31 is worst, so q8 is *lower* quality than q3, which is why q8 is
the smaller of the two JPEGs. That inversion catches people constantly.

A matched-quality comparison would need SSIM or butteraugli scoring on every
output. That would move the size column and is a different piece of work. What is
solid here is the ordering, which is large enough that calibration will not
reverse it.

## Where this stops

One frame, one 1280x720 photographic source, extracted at the two-second mark.
Content is the biggest variable in image compression: flat graphics and text
favour PNG and WebP's lossless mode dramatically, and none of that is visible in
a single photographic frame.

Image formats are one part of a wider codec comparison on the same source, collected in [Video codec comparison, measured](/blog/video-codec-comparison/).