WebP vs AVIF vs JPEG: which to ship in 2026
3 min read · Updated 2026-09-12
JPEG is from 1992 and still carries most of the images on the internet. WebP and AVIF both beat it on file size, sometimes dramatically. Whether you should switch depends much less on which compresses best and much more on what you are shipping, to whom, and how much encoding time you can spend.
The short version
| Use case | Format |
|---|---|
| Photos on a modern website | AVIF, with a WebP or JPEG fallback |
| Photos where you can only ship one file | WebP |
| Logos, icons, screenshots, anything with transparency | WebP (or PNG if the tooling demands it) |
| A file someone will open in unknown software | JPEG |
| An email attachment, a print shop, a government form | JPEG |
| An archive master you will re-edit later | None of these — keep the original |
Why the newer formats are smaller
JPEG compresses by dividing the image into 8×8 blocks and discarding the frequency detail within each block that human vision is least sensitive to. It is a clever design and it has aged remarkably well, but the block size is fixed and the toolbox is small.
WebP and AVIF are both derived from video codecs — WebP from VP8, AVIF from AV1 — and video codecs have spent thirty years getting very good at predicting one part of a picture from another. They can use variable block sizes, far more prediction modes, and smarter entropy coding. Applied to a single still frame, that machinery routinely produces a file 25–50% smaller than JPEG at the same perceived quality.
AVIF is the more capable of the two and produces the smallest files, particularly at low quality settings where JPEG falls apart into visible blocking and AVIF degrades much more gracefully.
The cost is encoding time
Better compression is bought with computation. Encoding an AVIF is meaningfully slower than encoding a JPEG — often by an order of magnitude at high effort settings. For a site that builds its images once and serves them a million times, that is a trivial cost. For a workflow that converts images on demand, or a user waiting on a progress bar, it is not.
Our WebP encoding runs at quality 90 with compression method 6, which is the slowest and most thorough setting the encoder offers. That choice is deliberate: WebP output is small enough to be worth the wait, and unlike video, a still image encodes in well under a second even at maximum effort.
Compatibility, honestly
WebP is supported in every current browser and has been for years. It is also supported by most modern image editors, though you will still occasionally meet an older tool, a CMS upload validator, or an enterprise system that rejects it.
AVIF is supported in current Chrome, Firefox, Safari, and Edge. Outside the browser it is patchier: plenty of desktop image viewers and editors still cannot open one, and support in non-browser software is where you will hit friction.
JPEG is supported by literally everything. That is its entire remaining advantage, and it is not a small one. If you cannot control what software will open the file, JPEG is the answer and the conversation ends there.
Where each one actually fails
- JPEG has no transparency. Convert a cutout to JPEG and the transparent area becomes a solid background — see the transparency guide for what happens to the edges.
- JPEG handles sharp edges badly. Text, screenshots, and line art get ringing artifacts around high-contrast boundaries; this is what makes a screenshotted JPEG look fuzzy in a way the original never did.
- WebP's lossy mode is subsampled by default, so very saturated reds can shift slightly. Rarely noticeable, occasionally maddening for brand colours.
- AVIF at aggressive quality settings smooths fine texture — grain, fabric, foliage — rather than blocking like JPEG. Smaller file, but detail genuinely goes missing rather than becoming visibly degraded, which is harder to spot in review.
A practical recommendation
If you are building a website and can serve different formats to different browsers, use a `<picture>` element with AVIF first, WebP second, and JPEG last. You get the smallest file each visitor's browser can handle, and nobody gets a broken image.
If you can only ship one file, ship WebP. It is close enough to AVIF on size, far better than JPEG, and supported widely enough that you will almost never hear about it.
If you are handing a file to a person rather than a browser — an email, an upload form, a printer — ship JPEG and stop thinking about it. The few hundred kilobytes you would save are not worth the one time it does not open.