Convert GIF to WebM

The reason to choose WebM over MP4 is not that it is better in the abstract; it is that a video element can list more than one source and the browser takes the first it understands. Put the WebM first and the MP4 after it, and every visitor gets the smaller file where their browser supports it and a working file where it does not.

That only works if you own the markup. A GIF being sent to a client, posted to a forum or dropped into a slide deck has no fallback mechanism, and there WebM is a worse choice than MP4 for a reason that has nothing to do with the codec. This page assumes you are editing the HTML yourself.

Both codecs work the same way in outline: store one complete frame, then store the differences. VP9 arrived roughly a decade later and spends considerably more effort per frame deciding how to partition the picture and where to search for matches, which buys real bytes on material that repeats.

GIF material is unusually good for it. Flat colour, hard edges, large unchanged regions and synthetic motion are all cases where a bigger search finds more, so the gap between VP9 and H.264 on a converted GIF is wider than the gap on camera footage. The cost is encoding time, which you pay once, in this tab, rather than on every page load.

The container’s record here lists it as streamable, and that is the second saving on a page. A browser can begin playing a WebM from its first bytes, so the animation starts while the rest is still coming down.

A GIF cannot do that in any useful sense. Browsers will show early frames as they arrive, but the loop does not run properly until the whole file has landed, which on a slow connection means a static first frame sitting there for seconds. Replacing a GIF with a WebM changes the shape of that wait as well as its length.

WebM is one of the very few video formats capable of storing transparency, and its record in this registry says so. That capability is real, and it is worth knowing about because it makes WebM the format people reach for when they want a video that floats over a page background.

The file this conversion writes does not use it. The video track is opaque, so a GIF whose background was declared transparent loses that on the way through, and there is no background-colour setting on this pair to control what replaces it. If transparency is the point of the animation, animated WebP is the honest recommendation: it keeps the alpha channel and it plays everywhere.

Every frame of a GIF is drawn from a palette of at most 256 colours. Whatever smooth gradient or soft shadow the animation started with was reduced to that when the GIF was written, often with dithering applied to hide the steps.

VP9 stores what it receives and imposes no palette of its own, so the animation does not get worse. It also cannot get better, and dithering is actively expensive: it is noise, and noise is the one thing that defeats a video codec’s search for redundancy. A heavily dithered GIF produces a larger WebM than a flat one of the same size, and raising the quality band spends bytes preserving the dither pattern rather than the picture.

GIF delays are per frame and stored in hundredths of a second, so a GIF frequently runs at rates no camera ever produced — 12.5 frames a second, or several different rates inside one file. The conversion carries each frame’s own duration into the video rather than resampling to a constant rate.

A stored delay of zero is common and means "as fast as the display allows"; browsers have long treated it as 100 milliseconds and so does this conversion. The practical result is that an animation timed by eye in a GIF editor plays at the same speed as a WebM, which is not something a fixed frame rate would have preserved.

Both video codecs used on this site want even pixel dimensions, and a GIF is under no such obligation. Widths and heights are rounded up to the next even number before the first frame is drawn, so a 405-pixel-wide GIF produces a 406-pixel-wide WebM.

Rounding up adds a column rather than removing one, which keeps the edge of the animation. If the video is laid out with a fixed CSS width the extra pixel never surfaces; if you are matching it against a background image pixel for pixel, it is worth knowing the number moved.

Replacing an image element with a video element is not a like-for-like swap and it is the step most likely to go wrong. The video needs an explicit width and height or an aspect-ratio rule, or the page reflows when it loads — which converts a bandwidth problem into a layout-shift problem and leaves the performance report no happier.

A poster frame is the other thing worth adding. Without one there is a blank rectangle until the first frames decode, where the GIF at least showed something. Exporting the first frame as a small WebP or PNG covers it.

The frames are read by the browser’s own image decoder and encoded by its own video encoder, in the tab you are looking at. There is no server in the path, no queue, no account and no daily allowance, and a batch takes 100 files at once.

That decoder is not present everywhere. Where it is missing the page says so and names browsers that have it, rather than quietly sending the file elsewhere to be finished — which is the one thing that would make the claim above untrue.