When a GIF is the wrong choice
A GIF is a 1989 image format doing a job it was never built for. Sometimes it is still the right one. Here is how to tell, and how to get a good one when it is.
A five-second clip that is 400 KB as an MP4 will routinely be 4 MB as a GIF, and it will look worse. Both of those facts come from the same place: the GIF format stores each frame as a full image with a palette of at most 256 colours, with no knowledge that one frame resembles the next and no ability to represent a gradient without visible banding. It has no audio and no real compression. It is, in effect, a flipbook of indexed PNGs.
Why anyone still uses it
Because it plays everywhere, automatically, with no player and no click. Drop a GIF into a markdown file, a GitHub issue, a wiki, an email, a support ticket or a presentation and it animates. A video file in the same places shows a thumbnail with a play button at best and a broken icon at worst. Messaging apps and social platforms have mostly solved this by quietly converting GIFs you send into silent MP4s and playing those, but documentation and email have not, and those are the places where a GIF earns its weight.
So the decision is about where the animation is going. If it goes anywhere that can play a video element, use a video. If it goes into a document, a README or an email, it probably has to be a GIF.
When it should be a video
A short MP4 with no audio track is between five and twenty times smaller than the equivalent GIF, supports full colour, and can be far longer than the two or three seconds a GIF can reasonably hold. On a web page, <video autoplay muted loop playsinline> behaves exactly like a GIF, including autoplaying on phones, which is what the muted and playsinline attributes are for. If you are producing something for your own site, make it an MP4 (or a WebM alongside it) and use that element. The compress tool with audio set to "remove" produces precisely this kind of file.
Animated WebP is a middle option: full colour, real compression, alpha transparency, and smaller than GIF by a large margin. Browser support is now universal, but support in documents and email clients is not, so it is a web-only answer.
Making a good GIF when it has to be one
Almost everything that makes GIFs look bad is fixable, and almost all of it comes down to the palette.
The palette problem
A GIF frame can use only 256 colours. The naive way to convert video is to use a single fixed palette of 256 "web-safe" colours for everything, which is why so many GIFs have posterised skin and grey skies: the palette had no colours near the ones the footage needed. The fix is to analyse the footage first and build a palette from the colours it actually contains. In FFmpeg this is a two-pass process, palettegen followed by paletteuse, and it is what the GIF tool here does on every run. The first pass reads the whole clip and picks the 256 colours that best cover it; the second pass converts the frames using that palette. The difference in output is not subtle.
The tool uses stats_mode=diff when building the palette, which weights the colours toward the parts of the frame that change between frames. For a screen recording where most of the frame is static background and the interesting part is a small moving region, this spends the palette where the eye is looking.
Dithering
With only 256 colours, a smooth gradient has to be faked by scattering pixels of the two nearest colours. That scattering is dithering, and the pattern used matters. Ordered (Bayer) dithering gives a regular, slightly crosshatched texture that compresses well and stays stable from frame to frame. Error-diffusion methods like Floyd-Steinberg look smoother on a still frame but produce noise that changes on every frame, which the eye reads as shimmer and which makes the file larger. The default here is Bayer for that reason. Turning dithering off entirely produces visible bands but the smallest files, which can be right for flat-coloured screen recordings where there are no gradients to smooth.
Frame rate and size
These are the two levers on file size, and they are blunt. A GIF's size is roughly proportional to width times height times frame count. Halving the width quarters the size. Going from 30 fps to 15 halves it, and 15 is enough for almost everything except fast motion; 10 or 12 is fine for UI recordings. The tool defaults to 15 fps and 480 pixels wide, which for a typical screen capture lands in the low single-digit megabytes. Going to 24 fps and 800 pixels wide will produce a file several times larger, and places that accept GIFs often have limits around 8 to 15 MB.
Duration
Trim first. A GIF should be the three seconds that matter, not the twenty seconds around them. Cut the clip with the trim tool before converting, or use the start and end fields on the GIF tool itself. A GIF that loops cleanly, where the last frame leads naturally into the first, reads as deliberate; one that jumps reads as a mistake. It is worth spending a moment on where the cut lands.
GIF from still images
The other direction, a handful of photos or screenshots played in sequence, goes through the same palette process and has one extra consideration: the images must be the same size. The images-to-GIF tool scales them to match. Photographs make poor GIFs for the palette reason above; a sequence of photos nearly always looks better as a short video made with images to video, with a second or two per frame.
A decision in four lines
- Going on a web page you control: silent MP4 in a video element. Not a GIF.
- Going into a chat or social post: either; the platform will convert it anyway, so send the smaller MP4.
- Going into a README, wiki, document, email or ticket: a GIF, made with a generated palette, at 15 fps, no wider than it needs to be, trimmed to the moment.
- Needs sound: not a GIF. It cannot carry any.