Convert WebM to WebP

A picture destined for a web page is judged by different criteria from one going into a document. Nobody will open it in an image viewer; it will be one of twenty things a browser downloads while somebody decides whether to stay. Its size in kilobytes is a real cost paid by every visitor, and its format has to be one that the CMS, the build step and the browser all accept without special handling.

That is the whole argument for WebP over JPG here. Same visible result, about thirty per cent fewer bytes, and universal support in current browsers. On a grid of a dozen tutorial thumbnails that is a third of the image weight removed for no visible change and no fallback markup — which is the kind of optimisation that survives contact with a real project.

WebP and WebM come from the same effort. Google released both around 2010 as royalty-free answers to patent-encumbered formats, and WebP’s still-image compression grew out of the intra-frame coding in VP8 — the video codec WebM was built around. Taking a still out of a WebM and writing it as a WebP is closer to a family resemblance than a translation.

It does not make the conversion lossless, and that is worth saying so nobody expects it to be. The frame is decoded to pixels and re-encoded from scratch, at a fixed quality of 82. What the family resemblance does buy is that the kinds of detail the video codec kept are the kinds the still encoder is good at keeping, which is why WebP stills from video hold up better than the numbers alone suggest.

The most useful thing to do with this conversion is also the most obvious once you see it: take a frame from the WebM and use it as that video’s `poster`. A browser shows the poster until playback begins, so the picture people see first is a real still from the video rather than a black rectangle or an unrelated stock image.

Take it from about a second in rather than from zero. The very first frame of a recording is often a fade, a blank state or a page still loading, and it is also the frame the video will paint the instant it starts — so a poster taken from a moment later gives the viewer something to look at without producing a visible jump at the start. Second zero gives you the least interesting frame in the file and a poster that duplicates it.

The frame comes out at the video’s own pixel dimensions with nothing scaled. A 1080p screen recording produces a 1920 by 1080 WebP; a 4K capture produces one at 3840 by 2160. That is deliberate — a frame has a real resolution and this conversion’s job is to hand it over intact rather than to guess at a display size.

The resizing belongs further down the chain. Whatever generates your responsive `srcset`, your CMS’s image pipeline, or your build step already knows which widths the layout needs, and it will do a better job from a full-resolution source than from one already reduced. Take the biggest honest version here and let the thing that knows the layout make the small ones.

The picture inside a WebM was encoded for motion. A video codec spends its bits where things move and economises where they do not, on the assumption that no single frame will be stared at. Freeze one and you are doing exactly what it assumed nobody would do.

The practical effect for a thumbnail is small, because a thumbnail is displayed at a fraction of its native size and downscaling hides softness rather well. It matters when the still is used large — a hero image, a full-width illustration — where a frame taken during a pan or a scroll will look visibly mushy next to the rest of the page. The fix is the timestamp: find a moment where the picture is still, and take it from there.

Browsers are no longer the problem; the long tail is elsewhere. Some email clients will not render WebP, so a newsletter thumbnail should be a JPG. A number of older desktop applications, print workflows and a few upload forms still reject the format. Windows and macOS both preview it fine now, which was not true a few years ago and is the source of most stale advice about it.

Inside a browser it is safe to treat WebP as universal, which is what makes it the pragmatic default rather than AVIF. If the destination is anything other than a web page — an email, a document, a printer, a form — take the JPG and stop thinking about it.

A library of tutorials needs a thumbnail each, and that means one conversion per video rather than one conversion per frame. Convert, note the timestamp that worked, move to the next file. The whole cycle is a couple of seconds because nothing is uploaded between attempts and there is no queue.

It is worth choosing the timestamps deliberately rather than accepting zero for all of them. A grid of thumbnails all showing an empty editor or a loading spinner tells a visitor nothing about which video is which, and that is exactly what taking the default frame from every file produces.

The recordings that need poster frames are usually the ones that have not shipped yet: a product demo, a feature walkthrough, a course module. Uploading the whole video to a converter so that it can hand back a 60 KB thumbnail is a lot of exposure for very little work.

The decode and the encode both happen in the tab, using codecs the browser already has for playing WebM. Nothing carrying the video is sent, there is no account and there is no daily limit — which also means converting thirty of them is the same operation thirty times rather than a reason to upgrade something.