The Complete Video to GIF Guide

The most common mistake is converting the whole clip and trimming afterwards. Scrub first, find the in and out points, and only then extract. Everything downstream gets cheaper.

Three seconds is a good target and shorter is usually better. A GIF loops, so a viewer sees the moment repeatedly; anything with dead air at the edges feels sluggish by the second pass. Cut into the action and out of it.

A browser will not hand over "frame 147" of an MP4 directly. What it will do is seek a video element to a timestamp and let you copy what it displays. Extraction is a loop of seek, wait for the seek to settle, capture, repeat.

WebCodecs is faster, but it requires unwrapping the container yourself and codec support inside those containers varies by browser and platform. Seeking works everywhere. When the alternative is a conversion that fails outright, universal beats fast.

Sampling rate has nothing to do with the source video's frame rate. You are asking for evenly spaced timestamps, and you can ask for two per second or thirty.

For most screen recordings 12.5 fps is indistinguishable from the original once it is looping in a chat window. Hand movement and fast cuts want 20–25. Above 25 you are paying linearly in bytes for frames the eye will not resolve at GIF dimensions.

Export at the size it will be displayed, not the size it was recorded. A 1080p screen recording shown in a 600 px column should be exported at 600 px; anything more is bytes spent on pixels nobody sees.

Some platforms re-encode what you upload. Twitter converts GIFs to MP4 on the way in, which means the colour reduction you carefully tuned gets thrown away and re-compressed — often visibly. If a platform accepts video directly, uploading MP4 avoids that round trip entirely and looks better.

Live-action video usually needs 128 colours and error-diffused dithering to keep gradients from banding. Screen recordings are the opposite: they are mostly flat, so 32–64 colours with dithering off is both smaller and cleaner.

Reach for these last. Halving the frame rate or the width will always get you further than a colour reduction, and the colour reduction is the lever people notice.

GIF has no audio track, so for GIF this is moot. For MP4 and WebM export it would be technically possible — and it is still not offered.

The reason is the timeline. Clips can be reordered, reversed, sped up and re-timed, and there is no honest way to keep a soundtrack in sync through those operations. An audio channel that is correct only when you have a single clip playing forward at 1× is worse than none, because it fails silently in exactly the cases people would rely on it.

A container is not a codec. MOV is a container; the ProRes inside it is what your browser cannot decode. The same applies to some phone-recorded HEVC in an MP4 wrapper — the extension looks fine and the file still will not play.

Re-encoding to H.264 in an MP4 container solves nearly all of these. It is also worth checking that the file is not DRM-protected, which no browser will decode regardless of codec.