Convert AVIF to WebP

Something in your toolchain accepts WebP and has never heard of AVIF. That is the reason, and it is a real one: a WordPress theme, a CMS uploader with a hard-coded MIME list, an ad specification written in 2021, a mobile app’s asset pipeline, a static site generator plugin that resizes what it recognises and passes the rest through untouched. WebP has been shipping since 2010 and AVIF since 2019, and nine years is roughly how far behind the average piece of image-handling software runs.

If that is your situation, this page is the fix and the cost is small. If it is not — if the reason is a belief that WebP is safer, better supported or more standard — then read the next section before converting, because you would be paying a lossy pass and some extra bytes for nothing at all. The test is easy to apply: name the specific piece of software that rejected the AVIF. If you cannot, the conversion is probably not the thing you need.

Every current browser reads both formats. That is the single most common misconception about this conversion, and it comes from the years when it was true: AVIF support arrived several years after WebP’s, so a lot of advice written in between is still online and still says WebP is the safe modern choice.

Neither is safe outside a browser. Email a WebP and email an AVIF and you have exactly the same problem — image viewers, older phone galleries, chat clients and print services are patchy about both. If the file has to survive contact with somebody else’s software rather than somebody else’s browser, the honest conversion is to JPG or PNG, not sideways between two web formats. The head-to-head between the two — where each actually wins, and what the encoding costs — is set out on this site’s WebP and AVIF comparison, which is the page to read if you are still choosing rather than converting.

Both are still frames of a video codec: WebP is a frame of VP8, published by Google in 2010; AVIF is a frame of AV1, published by the Alliance for Open Media in 2019. Converting between them means decoding one lossy encoding and producing another with a different, older model of what matters in a picture.

The second encoder cannot know what the first discarded, so it treats AVIF’s smoothed gradients and flattened texture as if they were the original scene and compresses them again. The damage at the default quality of 82 is modest and it is not zero. Where it shows first is the material AVIF is best at and VP8 is weakest at: skies, gradients, shadow detail and large flat areas that AVIF kept clean and WebP will band.

This is the hard limit people meet without expecting it. A WebP cannot be more than 16,383 pixels wide or tall — it is a property of the format, not of any particular encoder — while an AVIF can reach 65,536 on a side. Going from AVIF to WebP is therefore the one direction here where the target can be too small to hold the source at all.

It is not an abstract limit. A stitched panorama, a scanned map, a long screenshot of an entire page or a tiled product image can all cross 16,383 pixels comfortably. If yours does, set the maximum width control before converting, which resizes in the same pass that encodes. Resizing deliberately is far better than discovering the ceiling at the moment the file is needed, and it is one of the few cases on this site where the target format, rather than the source, is what limits the picture.

AVIF can describe up to twelve bits per channel and wide colour gamuts. WebP is eight bits in a standard gamut, and that is a ceiling in the specification rather than a setting. Anything the AVIF held above eight bits does not arrive.

For images that came off a web page this changes nothing, because they were eight bits when they were served. It matters for an AVIF exported from a modern camera or editing pipeline, where the extra precision was the reason AVIF was chosen: converting it to WebP discards exactly the property the format was picked for. In that case the conversion is a downgrade with a purpose, and it is worth being sure the purpose is real before a whole library goes through it, since nothing recovers the precision afterwards.

On photographic content AVIF is typically 20 to 30 per cent smaller than a comparable WebP, so the usual outcome of this conversion is a larger file. If you are converting because a build step needs WebP, that is a page-weight cost to be aware of and to weigh against whatever the build step is doing for you.

On flat interface graphics, icons, screenshots and line art the ordering reverses, and a WebP can come out smaller than the AVIF it was made from. That is measured on this site’s own WebP and AVIF comparison, where AVIF was twice as small on a photograph and noticeably larger on flat colour with hard edges. Convert two or three representative files of your own and compare the byte counts before deciding anything about a whole library.

Slow encoding is the failure mode this registry lists against AVIF, and it is the practical difference between the two. AV1 searches much harder for structure it can describe compactly than VP8 does — often an order of magnitude longer for the same image — which is where the smaller files come from and why a large AVIF can take several seconds even on a fast machine.

On this page you get the cheap half of that trade. Decoding an AVIF is fast and encoding a WebP is fast, so a batch of a few hundred images finishes in the time a single AVIF encode would take. For anyone converting a library rather than one file, this is the conversion direction that is comfortable to run in a browser — the reverse, turning a folder of WebPs into AVIFs, is the one that makes a laptop fan audible.

Both formats can hold animation — AVIF through its AV1 sequences, WebP since it gained animated support — so in principle an animated AVIF could become an animated WebP. This converter does not do that. It decodes one image and writes one image, so what you get back is a still WebP of the first frame.

That is stated here rather than discovered afterwards because a converter quietly dropping nine tenths of a file is the failure this site exists not to commit. If what you have actually moves and has to keep moving, neither of these formats is the answer and neither is this page: an MP4 produced from whatever created the animation is smaller than any animated image format for the same content and plays everywhere.

Transparency survives. Both formats carry a real alpha channel, so cut-outs, soft edges and semi-transparent overlays come across with the same precision they had, and no background colour has to be chosen. This is one of the few things about the pair that costs nothing.

One asymmetry is worth knowing: WebP’s lossless mode is excellent and widely supported by tooling, where AVIF’s exists and is less well handled. This page encodes lossy WebP, because that is what the quality control means and because an AVIF is almost always already lossy — writing a lossless WebP of a lossy image produces a much larger file that is not any more faithful to the original scene. If you need a genuinely lossless working copy, PNG is the target to use.

If the images are for your own pages, converting away from AVIF is rarely the right structural answer. A picture element with an AVIF source first, a WebP source second and a JPG fallback underneath lets every browser take the best file it can read, needs no detection and no maintenance, and means nobody has to choose.

The reason to convert instead is that something in the middle cannot be made to emit two files. That is common enough — plenty of platforms accept one image per asset — and it is a real constraint rather than a failure of nerve. Where it applies, convert, keep the AVIF, and revisit when the platform catches up. Everything runs in your browser here, so re-running the batch later costs nothing but time.