GIF or video: which to use when showing something moving
Some things can't be shown in a still image. An animation that stutters, a dropdown that closes too early, a three-step reproduction — these need motion, and you have two practical options.
The choice looks like a quality question. It's really a question about where the recording will be viewed.
What GIF actually is
GIF is an image format from the late 1980s that happens to support multiple frames. It has two properties that matter here.
It is limited to 256 colours per frame. Photographic content and smooth gradients band visibly. Interface recordings — flat colours, limited palette — survive much better, which is why GIFs of software often look acceptable while GIFs of video look terrible.
It has no modern compression between frames. Video codecs store what changed since the previous frame, which is enormously efficient for a screen recording where most of the picture is static. GIF has only rudimentary equivalents, so file sizes balloon with duration and motion.
A ten-second screen recording that would be a small MP4 can easily become a GIF several times larger.
No audio, ever. GIF has no audio track. If narration matters, GIF is already out.
What GIF is good at
It plays absolutely everywhere, automatically, with no controls and no interaction.
A GIF in a GitHub comment, a Slack message, or an email plays on its own. It loops. Nobody has to notice a play button. For a three-second demonstration of a UI glitch, that autoplay-and-loop behaviour is genuinely the right interaction model — the reader sees it without deciding to.
That's the actual case for GIF: short, silent, and somewhere that may not render a video player.
What video is good at
Better compression by a wide margin, real colour, audio, and the ability to scrub, pause, and replay.
For anything longer than about ten seconds, video wins on every axis that matters. A ninety-second walkthrough as a GIF would be an enormous file that nobody can pause. As an MP4 it's small and controllable.
The tradeoff is that video needs a player. Most modern platforms handle uploaded video fine, but "most" is doing real work in that sentence — some ticketing systems, wikis, and internal tools still don't.
A rule that works
Use GIF when all three hold:
- Under about ten seconds
- No audio needed
- Going somewhere that might not render video
Use video otherwise. Especially for anything with narration, anything over ten seconds, and anything where the viewer needs to pause on a specific moment.
Making GIFs less bad
If a GIF is right, a few things cut size dramatically:
- Crop tightly. File size scales with area. Cropping to the relevant quarter of the screen cuts roughly three quarters of the data.
- Cut the frame rate. Ten to fifteen frames per second is fine for interface motion. Thirty is usually wasted.
- Trim aggressively. Start at the action, end at the result. Dead frames at either end are pure cost.
- Avoid capturing video content. A GIF of a video player playing a video is the worst case for both the palette and the compression.
Crop and duration do most of the work. A tightly cropped five-second GIF is a manageable file; a full-screen twenty-second one is not, regardless of other settings.
The option people forget
Often the right answer is neither: two still images, before and after.
A lot of what gets recorded as motion is really a state change. If the
interesting thing is that the value was 3 and became 0, two screenshots show
that more clearly than a recording — the reader can compare them side by side
instead of watching a clip repeatedly to catch the moment.
Reach for motion when the timing or the sequence is the point. When it's the outcome, stills are better.