WebP vs AVIF vs JPEG: what to actually ship

Updated 12 October 2026 · 7 min read

Every format comparison you read will tell you AVIF is smallest, WebP is the pragmatic middle, and JPEG is the legacy option. All three statements are true and none of them tell you what to put on your server. Here is the decision, then the reasoning.

The short answer

Where the benchmarks mislead you

Format comparisons usually report bytes at equal SSIM or equal visual quality, and the winner depends entirely on the image. The patterns worth knowing:

Decode cost is the invisible tax

Everyone benchmarks encoding, but your users pay decoding. AVIF decoding is meaningfully more expensive than WebP or JPEG, which shows up as main-thread work on mid-range Android phones. If your page renders 30 AVIF images above the fold, you may have made the file sizes better and the experience worse. This is why "AVIF everywhere" is a bad default and "AVIF for hero images at build time, WebP for the long tail" is a good one.

Transparency and animated images

What to do about old browsers

WebP has been supported in every major browser for years, so a single-format strategy is defensible today. If your analytics still show a meaningful slice of legacy clients, use the picture element with two sources rather than JavaScript sniffing:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="800">
</picture>

The browser picks the first format it understands, in one request, with no redirect and no script. Add loading="lazy" for anything below the fold, and always set explicit width and height so the layout does not jump.

Where the real bytes are

Format choice is usually the second-biggest lever. The first is resolution: serving a 2000 px image into a 400 px slot wastes five times more bytes than any format decision will save you. Fix that before you spend a week building an AVIF pipeline.

Try WebP conversion in your browser →