Video to GIF

GIF's 256-colour cage, and why two passes matter

A GIF stores at most 256 distinct colours per frame, chosen from an indexed palette. A photograph or a UI gradient contains thousands, so converting to GIF means throwing most of them away — and how you choose which 256 to keep decides whether the result looks crisp or like a posterised mess. A naive single-pass conversion picks a generic palette and you get visible banding across every gradient and a grainy fringe on text. The two-pass approach this tool uses (the standard FFmpeg palettegen then paletteuse pipeline) first scans your specific clip to build a palette tuned to its colours, then maps every frame to that palette. On screen recordings and gradient-heavy footage the difference is dramatic.

Even with a perfect palette, 256 colours is a real constraint. Smooth photographic gradients — a sunset, a skin tone, a blurred background — will always dither or band somewhat in GIF, because the format simply can't represent them. That's not a bug in the encoder; it's the format showing its age. If your clip is mostly soft gradients rather than flat UI, that's your first signal a GIF is the wrong container.

Why GIFs are enormous — and the three levers that shrink them

GIF has no inter-frame compression worth the name. Modern video codecs encode mostly the differences between frames, so a near-static scene costs almost nothing; GIF re-encodes each frame largely from scratch via LZW, which is why a 10-second clip can balloon past 30 MB while the same clip as MP4 is under 1 MB. You can't fix the format, but three levers control the damage, in order of impact:

• Dimensions — the dominant cost. File size scales with pixel count, so halving the height (say 720p to 360p) cuts roughly to a quarter. Pick the smallest size that's still legible.
• Frame rate — GIFs look fine at 10-15 fps for UI and reactions; you rarely need 24+. Each frame is more bytes, so dropping fps is close to a linear saving.
• Duration — keep it under ~10-15 seconds. GIF size grows with every added frame, and a long GIF is exactly where the format is worst. Trim to the essential moment first.

When WebP, APNG or a muted MP4 beats GIF outright

The uncomfortable truth is that GIF is usually the wrong format for the job people reach for it. If your destination supports modern formats — and most do — animated WebP is typically 30-90% smaller than GIF at equal or better quality and supports more than 256 colours; an MP4/WebM looped muted plays even smaller and smoother. The one thing GIF still wins is universality: it auto-plays inline in nearly every chat app, email client, and ancient CMS without a video player, and it drops into a Markdown image tag. That compatibility is the entire reason to choose it.

If you only need it small, converting the frames or exporting differently beats GIF — it is a compatibility choice, not a quality one.

Picking framerate and dimensions that actually look right

Match the frame rate to the motion. A UI walkthrough — clicks, panel transitions, a cursor moving — reads perfectly at 12-15 fps and stays small. Fast, continuous motion (a game clip, a fast pan) looks choppy below ~20 fps, but that's also the kind of content where GIF is the wrong format anyway. For dimensions, decide where it will be viewed: a GIF embedded at 480 px wide in a README gains nothing from a 1080-px source except weight, so cap the height to roughly the display size. Capturing crisp on-screen text? Keep the height high enough that the text survives palette quantisation, then claw the size back with a lower frame rate and a shorter clip instead.