Skip to content
Server-sideDeleted in 30 minutes

Convert WebP to AVIF

Both formats are modern, both compress well, and both are supported by every current browser. AVIF is usually the smaller of the two, but the margin is narrow enough that this is the one conversion on this site where the honest answer is often "leave it alone" — and the page explains when it is not.

Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.

Add to Chrome — free
WEBPAVIF

Drop your WEBP file here, or click to browse

Up to 50 MB. Deleted automatically after 30 minutes.

What it does

  • Typically 20-30% smaller than the WebP
  • Alpha transparency carried across
  • Animated WebP reduced to its first frame
  • Says plainly when the conversion is not worth doing

How to use WebP to AVIF

  1. 1

    Add the WebP

    Images from a website's asset pipeline, exports from a design tool, or anything already optimized for the web. This conversion assumes the source is already reasonably compressed, which changes what to expect from it.

  2. 2

    Convert

    Encoding runs on our server, since browsers decode AVIF but cannot write it. Expect a few seconds per image — AVIF encoding is slow by design, and that cost buys the compression.

  3. 3

    Compare the two file sizes before switching

    Unlike converting from JPEG or PNG, the result here is sometimes barely different and occasionally larger. Check the numbers rather than assuming the newer format wins.

How it works

The WebP is decoded and re-encoded with libaom using AV1's still-image profile, with the alpha channel carried across as a separate plane. It runs on our server because no browser exposes an AV1 encoder to a web page.

Mechanically this is the same pipeline as converting a PNG or a JPEG. What differs is the starting point, and that changes the advice enough to be worth its own page.

Why the gain is smaller here

Converting a PNG to AVIF produces spectacular reductions because PNG was never designed for photographs — it is lossless, so a photographic PNG is enormous, and almost any lossy format beats it by an order of magnitude.

WebP is not in that position. It is a modern lossy format from 2010, derived from the VP8 video codec, and it is genuinely good. Converting to AVIF is not replacing something inadequate; it is swapping one competent codec for a slightly better one.

AVIF's advantage comes from AV1 being a decade newer than VP8, with better prediction and more flexible block sizes. That is worth 20 to 30 percent on a large photograph and very little on anything small or simple.

When it is worth doing

Large photographic images, especially above roughly 100 KB, where a third off is a real number.

High-traffic pages, where the saving multiplies by every visitor.

Image-heavy galleries, where the total transfer is what people feel.

When it is not

Small assets. Anything under about 10 KB, where container overhead eats the gain, as in the second example.

Icons and simple graphics. Few colors, hard edges, already tiny.

Animated WebP. Only the first frame survives.

Files you do not control end to end. If the WebP is going into an email or handed to someone to use elsewhere, AVIF's narrower support outside browsers is a real cost for no benefit.

The wider point

There is a habit of treating each new image format as an upgrade to apply everywhere, and the numbers rarely support it. The large wins come from leaving formats that were badly suited to the content in the first place — a photograph stored as PNG, a screenshot stored as JPEG. Moving between two formats that are both appropriate for the content, as here, is a marginal optimization, and it is worth measuring on your own images rather than assuming.

Examples

A large photographic hero image

hero.webp — 2400x1200, 186 KB
hero.avif — 2400x1200, 121 KB

About a third smaller. Large photographic images are where AVIF's advantage over WebP is real and worth collecting — the same picture, two thirds of the bandwidth, on every browser that matters.

A small UI icon with transparency

icon.webp — 64x64, 1.9 KB
icon.avif — 64x64, 2.4 KB

Larger, not smaller. AVIF's container carries about a kilobyte of overhead before any image data, which a 64-pixel icon cannot amortise. This is the clearest illustration of why small assets should stay as they are.

Frequently asked questions

Is AVIF always smaller than WebP?

No, and assuming so is the mistake this page exists to prevent. On large photographic images AVIF wins comfortably, often by 25 to 35 percent. On small images its container overhead cancels the gain and can reverse it, and on flat graphics with few colors the two are close enough that the difference is not worth an extra build step.

Both are supported everywhere. Why convert?

Bandwidth, and only bandwidth. Support is not the argument here — every current browser reads both — so the conversion is worth doing exactly when the byte saving matters: large images, high traffic, or users on slow connections. For a site serving a handful of small images it is effort without a benefit anyone will notice.

What happens to an animated WebP?

Only the first frame is converted. WebP's animation support is widely used for short loops that replaced GIFs, and although AVIF can hold an animation too, the tooling around it is far less reliable and support is patchier. Converting an animated WebP here gives you a still image, so leave animated files as they are.

Does converting lose quality?

Yes, in the same way as any lossy-to-lossy conversion. The WebP already discarded detail, and AVIF discards more on top. At the quality used here the difference is not visible on a photograph, but it is a second generation of loss, and it argues for converting from the original master where you still have one rather than from the WebP.