AVIF vs WebP

AVIF compresses harder. WebP encodes faster, is supported more widely outside the browser, and you can produce it with the tools you already have.

Head to head

File size
AVIF roughly 20–30% smaller at matched quality.
Encode speed
WebP wins decisively — AVIF is often 10× slower or more.
Decode speed
WebP is faster, which matters on low-powered devices.
Browser display support
Both universal among current browsers.
Browser encode support
WebP via canvas; AVIF generally not available.
Transparency
Both, full alpha.
Bit depth
WebP 8-bit; AVIF 10- and 12-bit, so far less banding.
Small images
WebP usually smaller — AVIF's container overhead dominates.

Choosing between them

Where AVIF wins

Raw compression. Typically 20–30% below WebP at matched visual quality, and the gap widens on large images and at low bitrates.

Gradients. 10- and 12-bit colour depth largely eliminates banding across skies and studio backdrops, which is a persistent weakness of every 8-bit format.

Low-quality resilience. At aggressive settings AVIF stays coherent where WebP softens. For thumbnails and blur-up placeholders this is a real advantage.

Where WebP wins

Encoding time. Often an order of magnitude faster. If images are encoded on demand rather than at build time, this decides it on its own.

Tooling. Every browser can write WebP through a canvas, which is why the tools on this site can produce it and cannot produce AVIF. Desktop and server support is also broader.

Decode cost. Lower, which matters on cheap phones rendering a long grid of images.

Small files. Below roughly 10 KB, AVIF's container overhead frequently makes it the larger of the two.

The recommendation

You have a build pipeline that generates multiple formats
AVIF first, WebP as the fallback, JPEG last. Captures the most bytes with no risk.
You optimise images by hand
WebP. It is already 25–35% below JPEG, encodes instantly, and you can produce it in a browser.
Images are generated on demand
WebP. AVIF encode times are not viable in a request cycle.
Large hero images with wide gradients
AVIF is worth the effort — the bit-depth advantage shows.
Icons, thumbnails, anything tiny
WebP, or PNG for flat graphics.

This is not an either/or

The <picture> element resolves the argument entirely. Offer AVIF, then WebP, then JPEG, and every browser takes the best it understands:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" width="1600" height="1067">
</picture>

The cost is generating and storing three files instead of one. Whether that is worth 20–30% on top of what WebP already saved is a question about your traffic and your build, not about which format is better.

Try it yourself

Everything below runs in your browser, so you can test any of this on your own files without uploading them.

  • Compress WebP

    Re-encode existing WebP files, or convert JPEG and PNG into WebP.

    Open the tool
  • JPG to WebP

    Typically 25–35% smaller at matched quality. The standard web win.

    Open the tool
  • Bulk compressor

    One setting across a whole folder, processed in parallel, downloaded as a ZIP.

    Open the tool
  • Compress JPEG

    Shrink JPG and JPEG photographs with a quality slider or an exact target size.

    Open the tool

Questions

Frequently asked questions

Every answer below is present in the page source, expanded, so it can be read without opening anything.

Which should I choose if I can only pick one?

WebP. It captures the majority of the available saving over JPEG, encodes quickly enough for any workflow, is supported everywhere including in browser tooling, and never surprises you on small files.

Why can I make WebP here but not AVIF?

Because these tools encode through your browser's canvas, and browsers expose a WebP encoder but generally not an AVIF one. Rather than offer an AVIF option that would silently return a PNG, the tools probe what your browser can actually write and disable anything it cannot.

Is AVIF worth the extra encoding time?

For a build pipeline that runs once per image and serves it thousands of times, easily. For on-demand encoding, almost never — the latency cost lands on every request while the byte saving is modest on top of WebP.

Do both support transparency?

Yes, both carry a full alpha channel, and either can replace PNG for transparent graphics on the web.

Which handles gradients better?

AVIF, clearly. Its 10- and 12-bit colour depth gives far more intermediate values than WebP's 8-bit, so wide gradients such as skies band much less.

What about JPEG XL?

Technically impressive — particularly its ability to losslessly repack an existing JPEG about 20% smaller — but browser support has not settled, which makes it hard to recommend for production today. AVIF and WebP are the practical choices.

From the blog

Related reading

Longer, more practical guides from the blog.

  • Image Formats

    WebP vs JPEG: Which Should You Use, and When JPEG Still Wins

    WebP produced a 27.0 KB file against MozJPEG's 41.1 KB on the same photograph at slightly higher measured fidelity — 34% smaller. It also produced a larger file than JPEG on random noise. The advantage is real and content-dependent.

    9 min read

  • Practical Guides

    How to Compress Images for a Website Without Wrecking Them

    Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.

    8 min read

  • Image Formats

    PNG vs JPEG: When to Use Each, With the File Sizes to Prove It

    PNG stored the same photograph in 1274.1 KB where JPEG needed 67.5 KB — nineteen times larger. On a flat graphic PNG won. On a smooth gradient PNG lost to JPEG by a factor of two, which surprises most people.

    9 min read