Squeezing an already efficient file
WebP was the format that finally displaced JPG on well-optimised websites, and AVIF is the format that is now displacing WebP for the same reason: at a comparable visual level it is typically 20 to 30 percent smaller, sometimes more on smooth photographic content. If you have a folder of WebP images that were exported from a site build, a CMS or a batch script, converting them to AVIF is a way to shave more off a page without touching the source material.
That last part is also the catch. Most WebP files are lossy, and encoding a lossy file with another lossy codec compounds the loss. Where you still have the original PNG or JPG, convert from that instead using PNG to AVIF or JPG to AVIF; the result will be cleaner at the same size. Use this page when the WebP is all you have.
What the encoder does with the file
The WebP is decoded by the browser, the raw pixels go to a Web Worker, and libaom compiled to WebAssembly produces the AVIF. Nothing leaves your device. Specifically:
- The alpha channel is preserved. A transparent WebP becomes a transparent AVIF, with soft edges intact.
- Animation is not preserved. An animated WebP contributes only its first frame, because the browser decoder exposes nothing else. AVIF itself supports animation, but this tool does not produce it.
- A lossless WebP is treated like any other source: the output is lossy according to the slider. There is no lossless AVIF option here.
- Metadata and colour profiles are removed. The AVIF is 8-bit sRGB with the original pixel dimensions.
Choosing quality when the input is lossy
The slider runs from 20 to 95, default 80, and AVIF's scale is not the same as WebP's. Because the source has already been smoothed once, keep the setting at 75 or higher; a second smoothing pass at low quality gives images a waxy, painted look, especially on skin, grass and fabric. Check the result at full size against the WebP. If it looks softer than the source, raise the value; the size gain is not worth a visibly degraded image.
Typical outcomes:
- A 1600x900 hero image of 240 KB as lossy WebP usually becomes 140 to 190 KB as AVIF at quality 80. The saving is real but smaller than headline figures suggest, because the WebP was already efficient.
- A 1200x800 lossless WebP illustration of 650 KB typically drops to 70 to 130 KB, since here AVIF is the first lossy step and the gain is large.
- A 200x200 icon of 6 KB as WebP may come out at 5 to 8 KB. At tiny sizes the AVIF container overhead cancels the codec advantage, so leave small icons alone.
AVIF encoding is slow by design. A two-megapixel image takes a second or two on a laptop and several seconds on a phone, and files are processed one after another.
The compatibility gap you are stepping into
Every browser that displays WebP also displays AVIF, with one important exception: Safari only added AVIF in version 16.4, so iPhones and Macs on older releases show nothing. Outside the browser the gap is wider. Windows needs an extension, many CMS thumbnailers and image proxies do not understand AVIF, and email clients mostly ignore it. The safe pattern for a website is to keep the WebP and offer the AVIF alongside it through the picture element, letting each browser pick the best format it supports. WebP vs AVIF vs JPEG lays out the support table and the size differences with real measurements.
Where this converter stops
It produces a single-frame, 8-bit, sRGB AVIF, nothing more. It cannot resize, so oversized sources should go through Resize image first. It cannot produce HDR, 10-bit or lossless AVIF. Very large sources are limited by how much canvas memory your browser will allocate, and the encode time grows with pixel count, so a 30-megapixel file on a phone may take a minute or fail outright.