AVIF to WebP

Drop AVIF images and get WebP copies back in this tab. Your browser decodes the AVIF — no library, no upload — and the pixels are re-encoded as WebP at the quality you pick. WebP keeps the alpha channel, so there is no matte step on this page: the only lossy choice here is the one slider you move.

Drop AVIF images here

or choose files · up to 30 at a time · still or animated · 8-bit, 10-bit or tiled

AVIF in, WebP out · still, animated, tiled or 10-bit AVIF · up to 30 files per batch · quality 40–100 · no upload · no account · no watermark

AVIF to WebP: The Conversion That Usually Makes the File Bigger

Here is the number this page exists to show. The same 1600 × 1200 photograph arrives as a 204,487-byte AVIF and leaves as a 322,456-byte WebP at the default quality of 82 — 58% larger, for a picture that already lost its detail to the AVIF encoder. WebP is not an upgrade here. It is the older codec: VP8-based WebP came first, AVIF is built on AV1, and on a photograph the newer one is simply better at spending bits. So this conversion is not about saving space. It is about producing a file that older software will actually open, at a size you choose with your eyes open.

The whole curve, measured on that file with this tool:

• quality 40 — 177,822 bytes, 32.07 dB, 98.76% of pixels changed
• quality 60 — 225,030 bytes, 34.30 dB
• quality 82 — 322,456 bytes, 38.46 dB — 58% larger than the AVIF
• quality 95 — 548,852 bytes, 44.62 dB — 168% larger
• quality 100 — 1,691,600 bytes, lossless, 0 pixels changed

Only one of those five settings produced a smaller file than the AVIF, and it is the one where a tenth of the picture's pixels moved by more than 48 levels. That is the trade, stated without decoration.

The dial is a size budget, not a quality promise

Every step up the slider bought fidelity and paid for it in bytes: 32.07 dB to 44.62 dB cost 371,030 bytes between quality 40 and 95. PSNR is a blunt instrument — it averages over the whole frame and says nothing about the one edge you care about — but it does move monotonically here, which means the slider is doing what it says.

What it cannot tell you is which step is enough. That depends on the picture: a product shot on white tolerates 60, a portrait at 82 usually looks untouched, and text on a coloured background is where 40 falls apart. Convert at two settings and compare the cards before you download.

100 is lossless, and the file shows it

At quality 100 the encoder switches to WebP's lossless mode: max pixel difference 0, alpha identical, and 1,691,600 bytes — 8.3 times the source AVIF, and still smaller than the PNG of the same photograph (3,179,872 bytes, measured on the AVIF to PNG page). If your destination needs a lossless WebP, this is the only setting that gives you one, and the size is what it is.

Alpha survives, and it is not the expensive part

A 600 × 400 AVIF with a cut-out subject and 116,186 fully transparent pixels came out at 2,257 bytes in and 5,280 bytes out at quality 82 — 2.3 times larger, 40.35 dB, with all 116,186 transparent pixels still transparent and the alpha channel identical on 100% of pixels.

Two things follow. First, WebP keeps 8-bit alpha, so unlike a JPG there is no matte colour to choose and no soft edge to lose. Second, the transparency did not inflate the file: the growth here (2.3×) is smaller than the photograph's (1.6× at the same quality on a much larger image), and none of it is a separate alpha channel cost you can dial away.

When this conversion is the right one

• Software that cannot read AVIF. Older Safari, older Android WebView, some CMS uploaders, a fair number of desktop editors. WebP is far more widely accepted than AVIF and far less accepted than JPG.
• A predictable quality dial. WebP's quality factor behaves the way most people expect; AVIF encoders vary by implementation, and the "quality 80" of one tool is not the "quality 80" of another.
• An animated sequence. Animated WebP is well supported; animated AVIF is not, which is why the panel reports the frame count and keeps the first frame.

If none of those apply and the file is only going to a modern browser, keeping the AVIF costs you nothing and saves 58%.

How to convert AVIF to WebP here

1. Add the AVIFs. Drop them on the box above or choose files — up to 30 at a time, 100 MB each.
2. Move the quality slider. It starts at 82 and re-encodes about a fifth of a second after you stop; there is no run button.
3. Read the cards. Each one shows the dimensions, the ratio, and in → out with the percentage change against the AVIF.
4. Download. One link per card, or the button under the panel for a ZIP built in the tab.

What each control does

Quality maps straight onto the encoder: 82 sends 0.82, and the number box beside the slider accepts a typed value and stays in step. The range is 40 to 100; below 40 WebP's blocking on gradients is the first thing anyone notices, and above 95 the file outgrows the AVIF by a wide margin. There is no matte control because WebP carries alpha, and no size control because this page keeps the source dimensions — an AVIF that needs resizing should be resized, not converted and resized in one step.

Why this page doesn't upload your AVIF

The AVIF decoder and the WebP encoder are both part of the browser, so the conversion has nowhere to happen but your own machine. A server would add an upload of a file that may be a client's photograph, a queue, and a download of something the tab could have written itself.

The check is the usual one: DevTools, Network tab, convert — no request carries the image. Then try it with the network disconnected, which is the version that cannot be faked by a clever UI.

Questions that come up

Why is the WebP bigger than the AVIF I started with? Because AVIF is the more efficient codec on photographs. At quality 82 the test photo went from 204,487 to 322,456 bytes, and at 95 to 548,852. Only quality 40 came in under the source, at 177,822 bytes and 32.07 dB. If size is the goal, keep the AVIF.

Which quality should I pick? 82 is a reasonable default: on the test photo it measured 38.46 dB, close to the AVIF's own fidelity. Drop to 60 for thumbnails and previews, where 34.30 dB is plenty at a third less size than 82. Go up to 95 only when the image is the product and the extra 226,396 bytes are cheaper than a reshoot.

Is quality 100 really lossless? For the pixels the browser decoded, yes: 0 pixels differed, and the file was 1,691,600 bytes. It does not recover anything the AVIF encoder discarded before this page saw the file, and it is 8.3 times the AVIF's size, so it is a format decision rather than a quality one.

Does the transparency survive? Yes, as 8-bit alpha, with no matte step: on the 600 × 400 test file all 116,186 fully transparent pixels stayed transparent and the alpha channel matched on 100% of pixels. A JPG conversion of the same file would have to paint them onto a colour you pick.

What happens to the other frames of an animated AVIF? Only the first frame is converted, and the card reports how many frames the file contained (the 480 × 270 test file has 42). Animated AVIF uses container tracks that a canvas cannot step through; you would need a demuxer to get the sequence out.

Can I go back to AVIF afterwards? Not with this page, and not usefully: re-encoding the WebP as AVIF would approximate already-approximated pixels a second time. If the AVIF is your master, keep it and treat the WebP as the compatibility copy.

If you need lossless pixels or an alpha channel that survives another round of editing, AVIF to PNG is the exact copy at 15.5 times the size; if you need the widest compatibility at the smallest size, AVIF to JPG flattens transparency and encodes at a quality you choose. Going the other way — WebP into another format — is covered by WebP to JPG and WebP to PNG.