Convert WebM to AVIF

AVIF is worth its awkwardness only when the size of an image is a number somebody is actually looking at: a largest-contentful-paint figure that will not come down, a page-weight target in a performance budget, a Lighthouse score being argued about in a pull request. If none of those apply, the WebP version of the same frame is smaller than a JPG, encodes instantly and needs no fallback — take that and move on.

Where the budget is real, AVIF is the strongest option available and the difference on a hero image or a large poster frame is not marginal. The cost is paid twice: in encoding time now, and in a fallback in your markup later. Both are manageable. Neither is free, and a page that pretended otherwise would be selling you complexity you did not need.

AVIF is not a new image codec. It is an AV1 intra frame — a single keyframe from the video codec — wrapped in the same container family as HEIC. And AV1 is one of the codecs a WebM can carry: newer browser recorders and most modern web video use it.

So when the source is an AV1 WebM, this conversion decodes a frame that AV1 encoded and hands it back to AV1 to encode again as a still. The round trip is unusually kind, because the artefacts the first pass introduced are exactly the shapes the second pass is efficient at describing. It is not lossless — the frame is fully decoded to pixels in between — but it is the closest thing to a family conversion in this bundle, and it is one reason AVIF stills from video hold up so well at small sizes.

A JPG or a WebP appears essentially at once. An AVIF takes seconds, and on a 4K frame on a modest laptop it can take rather more than a few. This is not the page being slow; it is what AV1 encoding costs.

The reason is the search. AV1 gets its efficiency from an enormous number of ways to describe each block of pixels, and the encoder tries a great many of them before choosing. That is a fine trade for a file that will be served a million times and a poor one for a file you are going to look at once. If you find yourself converting thirty frames and waiting, that is the signal to use WebP for the thumbnails and reserve AVIF for the one image at the top of the page.

The frame comes out at the video’s own pixel dimensions, unscaled, encoded at a fixed quality of 82. A 1080p recording yields a 1920 by 1080 AVIF; a 4K capture yields one four times the area and takes noticeably longer to produce.

Resize afterwards rather than here. Whatever generates your responsive sources knows the widths your layout needs, and it will do better work starting from the full frame than from a reduced one. It is also the place to decide how many sizes are worth the encoding time, which for AVIF is a real question in a way it is not for JPG.

Every current major browser decodes AVIF, but support landed years after WebP and older installations persist — particularly on devices that no longer receive updates. Serving AVIF alone is a decision to lose those visitors’ images rather than to slow them down.

The remedy is a `<picture>` element with an AVIF source, a WebP source and a JPG as the final `<img>`. Three lines, no JavaScript, and the browser picks the first one it understands. If you are already doing that for your other images, this frame slots into the same pipeline. If you are not, adding it is the prerequisite for using AVIF at all.

A still lifted out of compressed video carries whatever the video codec did to it. Bits were spent on motion, colour is stored at half resolution in each direction, and a frame taken during a scroll or a pan was never sharply encoded in the first place. AVIF preserves all of that very efficiently; it does not repair any of it.

The practical consequence is that the timestamp matters more than the format. A frame taken at a still moment and saved as JPG beats a frame taken mid-motion and saved as AVIF by a wide margin, on every measure including size — because a smeared frame is full of detail the encoder has to spend bits describing. Choosing the moment is the optimisation; choosing the codec is the rounding.

Anything that is not a web page. Email clients do not render it. Office software largely does not. Print workflows do not. Upload forms on other people’s sites frequently reject the extension outright, and a colleague sent an AVIF will more often than not reply asking what it is.

Its entire case rests on being decoded by a browser and served over a network you are paying for. For a slide, a document or a message, take the JPG; for an archive or a print job, take the TIFF. Using AVIF outside the case it was designed for produces a smaller file that nobody can open, which is not an optimisation.

AVIF encoding is expensive enough that services which offer it either charge for it, queue it or limit how many you may do. Here it runs in your browser, which is why the only ceilings are the ones printed above the drop zone — 100 files in a batch, 100 MB per file — and no daily allowance is spent behind them: the cost is your own processor, and you were the one who decided the trade was worth it.

It also means the video never leaves the machine. That is the usual privacy argument and it has a practical edge on this pair — a large recording uploaded to produce a 40 KB image is an absurd amount of network for the result, and it is the shape almost every other converter for this pair takes.