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
- Ship WebP to everyone, plus a JPEG fallback if your audience includes old browsers. It is supported everywhere that matters, encodes in milliseconds, and lands 25–35% smaller than JPEG.
- Add AVIF only if you can generate it at build time and you have measured that it helps. Typical saving over WebP is another 15–30%, at roughly 5–20× the encoding cost and with real quality caveats at low bitrates.
- Keep JPEG for anything that leaves software — print, older CMS uploads, email attachments, government forms.
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:
- Photographs with detail (foliage, crowds, texture): AVIF wins clearly, WebP wins comfortably over JPEG.
- Smooth gradients (skies, studio backdrops): AVIF's strongest case. JPEG will band noticeably at the same file size.
- Flat illustrations and screenshots with text: PNG often beats all of them at the same visual fidelity, and lossy formats produce ugly ringing around lettering. Do not blindly push UI screenshots through a lossy pipeline.
- Tiny images (under a few KB): header and encoding-table overhead dominates, and differences collapse to nothing. Optimizing a 4 KB file is wasted effort.
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
- Transparency: WebP and AVIF both support alpha; JPEG does not. If you flatten a transparent PNG to JPEG, you get black or white boxes — always check before shipping.
- Animation: animated WebP is well supported; animated AVIF is not, in practice. For short animations, a muted MP4 or WebM is usually smaller and smoother than an animated image format.
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.