Convert MKV to GIF

This conversion samples frames at evenly spaced moments counted from zero. There is no start-time control and no way to add one, so whatever the first seconds of the file contain is what the GIF will show. On a short clip that is fine and usually what was wanted.

On a Matroska file it is almost never what was wanted, because these are long recordings — a film, a stream archive, a captured session — and the moment somebody wants is forty minutes in. The default result is ten seconds of a black frame or a distributor’s logo, which reads as a broken tool rather than as a missing feature. It is neither: it is the wrong order of operations.

The fix is one extra step and it takes about a minute. Use the video trimmer here: give it the second the moment starts and the second it ends, and it returns just that span. Then bring the result to a GIF conversion, where starting at the beginning is now exactly what you want.

The trimmer hands back an MP4 whatever went in, so the second conversion is MP4 to GIF rather than this page — which is fine and is the same code doing the same job. It is worth knowing that the trim re-encodes rather than cutting at the nearest keyframe: the cut lands on the second you asked for, and the picture passes through a decoder and an encoder before the GIF stage sees it at all.

Ten seconds, 480 pixels wide, twelve frames a second. Those are deliberately modest and they exist because GIF has no concept of motion: it stores every frame as a complete image with at most 256 colours, one after another, with nothing describing what stayed the same. Every one of those three numbers multiplies the file size almost directly.

A ninety-second 1080p clip at its original frame rate would be a GIF of several hundred megabytes that no browser would display and no service would accept. The defaults produce something that fits in a chat window, an issue tracker or a documentation page, which is where GIFs actually go. Raise them deliberately and check the result, rather than assuming a larger number is better.

There is a hard limit of 600 frames on the encoder, and the Length control accepts up to sixty seconds without knowing about it. The two only agree at low frame rates: sixty seconds at twelve frames a second is 720 frames, so the result is cut to fifty. At thirty frames a second the same request yields twenty seconds.

The arithmetic is 600 divided by your frame rate, and it is worth doing before rather than being surprised after, because nothing on the page announces the truncation. The limit exists because a browser tab runs out of memory holding more than that many full frames — it is a real constraint rather than a policy, and the way around it is a shorter clip or a lower frame rate.

Each frame gets its own palette of 256 colours, chosen from what is actually in that frame. Per-frame rather than one palette for the whole clip is the more expensive choice and the only one that survives a cut: a single palette built on a bright scene renders a dark one in the wrong colours entirely.

No dithering is applied, and that is where the visible cost lands. Dithering scatters pixels to fake the colours a palette lacks; without it, a smooth gradient — a sky, a lit wall, a slow fade — becomes a set of visible bands. Flat graphics, interface panels, animation and screen recordings hold up extremely well because they contain few colours to begin with. Film and camera footage show it immediately.

GIF has no audio track, has never had one, and there is nothing in this conversion that could carry sound across. A moment that works because of what somebody says does not work as a GIF, and no setting recovers it.

It is worth pausing on because the destinations that require GIF are fewer than people assume. Most platforms that accept a GIF accept a short video too and will silently convert your GIF into one after you upload it — at which point you have paid GIF’s costs and received none of its compatibility. The places where GIF genuinely still wins are old forums, wikis, issue trackers, email signatures and documentation that cannot embed a player.

Four widths are offered — 320, 480, 640 and 800 pixels — and the height follows automatically so nothing is stretched. A 4K or 1080p recording has to come down a long way, and that is not a compromise: a GIF displayed in a chat window or a README is being shown at a few hundred pixels regardless of what is inside it.

The relationship is quadratic, so doubling the width roughly quadruples the frame data before compression. Going from 480 to 800 is a much larger change than it looks. Start at the default, look at the result at the size it will actually be displayed, and raise it only if something specific is unreadable.

The decoding, the resizing, the palette selection for each frame and the GIF assembly all happen on your own machine. Nothing carrying the recording is sent anywhere, there is no queue, and there is no watermark — the file is written by the same code whether you convert one clip or thirty.

It is also work, and a long clip at a high frame rate is hundreds of full images being quantised one after another. Expect a GIF to take longer than a still and about as long as a short video conversion. The free tier accepts an MKV up to 100 MB, which is another reason the trim-first route is the right one: a ten-second clip cut out of a two-hour recording is a small file by the time it reaches this page.