WebP vs AVIF
AVIF compresses harder; WebP encodes faster and is easier to produce. What separates them in practice, and how to serve both without betting the site on either.
By Wajahat Rasoul ·
Where each came from
Both are still-image formats derived from video codecs, which is why both compress photographs so much better than JPG.
- WebP came out of Google's VP8 work. It has been around long enough that browser support is now universal, and it offers both lossy and lossless modes plus transparency.
- AVIF is built on AV1, a newer and considerably more sophisticated codec. It supports transparency, wide colour and high dynamic range, and compresses harder — particularly at low bitrates.
How they compare
| WebP | AVIF | |
|---|---|---|
| Compression at equal quality | Good | Better, often noticeably |
| Behaviour at very low bitrates | Blocky | Smooth, sometimes waxy |
| Transparency | Yes | Yes |
| Wide colour / HDR | No | Yes |
| Encoding speed | Fast | Slow — often much slower |
| Browser support | Universal in current browsers | All current major browsers, thinner further back |
| Tooling outside browsers | Widely supported | Improving, still patchier |
Where AVIF genuinely wins
- Large photographic images on a performance budget. This is AVIF's home ground, and the saving over WebP can be substantial.
- Aggressive compression. Where JPG blocks and WebP smears, AVIF degrades gracefully — helpful for placeholders and low-priority imagery.
- Wide-gamut or HDR content. WebP has no answer here; it is limited to 8-bit sRGB.
The characteristic AVIF failure at very low quality is not blockiness but loss of fine texture — skin and foliage can look slightly plastic. It is less objectionable than JPG blocking, but it is not nothing.
Where WebP is still the better bet
- Anything you have to produce at volume. AVIF encoding is markedly slower. Across a large batch that difference is felt.
- Small images. At thumbnail sizes the gap narrows, and AVIF headers can even leave it ahead on bytes.
- Files that leave your control. Desktop software, upload portals and older systems are further along with WebP than with AVIF — and both trail JPG, which is why converting back to JPG remains a real need.
- Browser-based tooling. Browsers can encode WebP from a canvas; AVIF encoding is not available that way, which is precisely why the tools here — which run entirely on your device — offer JPG to WebP and PNG to WebP and not AVIF.
Serving both without picking a side
On a website you do not have to choose. The <picture> element lets the browser take the first format it understands:
- An AVIF
<source>first, a WebP<source>second, and a plain<img>with a JPG as the final fallback. - Set
widthandheighton the<img>regardless of format, so the layout does not shift while images load. - Most modern site frameworks and image CDNs will do the whole negotiation for you; check before building it by hand.
The rest of the delivery checklist is in optimising images for websites.
A reasonable default
If you are shipping images from a pipeline that can produce both, serve AVIF with a WebP fallback and stop thinking about it.
If you are converting files by hand, or handing them to someone else, WebP is the pragmatic choice — the compression win over JPG is already large, it encodes quickly, and it is far more likely to open wherever it lands. And if the destination is a portal, a print shop or unknown desktop software, send JPG. The older comparison still decides more cases than this one does.
What about JPEG XL?
Technically strong and well liked by photographers, but browser support has been unsettled. It is not a format to build a delivery pipeline on today without checking the current state of support for yourself.