Convert MP4 to AVIF

There is a neatness to this pair that the other frame grabs do not have. An MP4 usually holds H.264 or HEVC; an AVIF is a still frame of AV1, the next generation of the same lineage of video codecs. The picture is being handed from one member of the family to another.

That is why the result is so compact. Everything AV1 learned about describing a single frame efficiently applies to a frame that came out of a video in the first place, and the output is routinely a fraction of what the same still would be as a JPG.

On photographic content, AVIF typically lands twenty to thirty per cent below an equivalent WebP and well below a JPG. It also handles the material that video stills are full of — dark scenes, studio backdrops, skies, smooth gradients — with noticeably less banding, because it is not confined to eight bits per channel.

For a video poster image that is the strongest case available. The poster loads before anything plays, on every visit, and it is frequently the heaviest single asset on a page carrying video. Taking a third off it is worth more than the same saving anywhere else on the page.

AVIF searches far harder than WebP or JPEG do, and it takes the time that implies — several seconds for a single high-resolution frame is ordinary, even on a fast machine.

Paid once, at build time, by you, that cost is irrelevant and every visitor benefits. Paid on demand, by a server generating thumbnails as videos are uploaded, it becomes a capacity question with a bill attached. That distinction is the honest answer to whether AVIF belongs in a given pipeline, and it is why so many services still generate WebP.

A frame from a screen recording, a slide, a title card or anything mostly flat colour and hard edges. That material compresses extremely well already, and AVIF frequently produces a larger file than WebP for it — the opposite of the expected result, and worth measuring rather than assuming.

And anywhere outside a browser. Image viewers, older phone galleries, chat applications, email clients and plenty of upload forms still refuse the format. An AVIF is a file you serve, not a file you send: for a still going to a person, take JPG.

No encoder recovers detail the video never had. A frame grabbed mid-movement carries the motion blur and blocking the codec left there, and encoding it beautifully preserves them beautifully.

So the timestamp remains the first lever: a moment when the subject is still, or the first frame after a cut where the encoder placed a full-detail keyframe. Get the frame right, then let AVIF make it small. Doing it in the other order produces a very efficient copy of a poor picture.

The arrangement that makes this worth doing is a picture element with an AVIF source first, a WebP source second and a JPG fallback — every browser takes the best it understands, and nothing has to be detected.

For a video poster specifically, the attribute takes a single image, so the usual approach is to serve the format the browser advertises through your image pipeline or CDN, or to accept WebP there and use AVIF for the thumbnail grid around it. Either is reasonable; serving AVIF alone with no fallback is the one arrangement worth avoiding, since it costs nothing to keep one.

Both halves happen in the browser tab on your own processor: the video is decoded and the frame is encoded, with nothing sent anywhere. A large video is read from disk rather than transferred, which on any hosted converter is slower than the work itself.

The second half matters more than usual for this pair. AVIF encoding is genuinely expensive, and doing it locally means the cost is your own machine for a few seconds rather than a queue, an allowance or a subscription somewhere else.