What GIF is doing to each frame
GIF stores an animation as a sequence of images compressed with LZW, a general-purpose lossless algorithm that looks for repeated byte patterns. Critically, its compression works within each frame and, in the best case, stores only the rectangle that changed between frames. It has no concept of motion.
This is the central inefficiency. Modern video codecs achieve their size by predicting: they encode a keyframe, then describe subsequent frames as motion vectors — 'this block of pixels moved eleven pixels left' — plus a small correction. A panning shot is nearly free to a video codec, because almost everything simply moved. To GIF, a panning shot means every pixel in every frame changed, so nothing can be skipped and every frame is stored close to whole.
That is why camera movement destroys GIF file size while a static shot with a small moving element stays reasonable. It is also why the advice 'crop the GIF' works so well: you are removing pixels that were being stored repeatedly.
The 256-colour limit
A GIF frame can contain at most 256 distinct colours, drawn from a palette stored in the file. A photograph or a video frame typically contains tens of thousands. Reducing that to 256 is where most of the visible quality loss comes from — not from the compression, which is lossless, but from the palette.
Two techniques manage the reduction. Palette selection picks the 256 colours that best represent the frame, which is why a clip with a narrow colour range survives well and a colourful one does not. Dithering scatters pixels of available colours to simulate missing ones, trading banding for a fine noise texture.
Dithering has a cruel interaction with the compression. LZW compresses repeated patterns, and dithering deliberately introduces high-frequency noise, which has no repeated patterns. So turning dithering up to fix banding can substantially increase the file size. Gradients — skies, shadows, fades — are the worst case for GIF: they band badly without dithering and inflate badly with it.
- Narrow palettes (cartoons, screencasts, line art) compress well.
- Gradients and skies band or bloat, with no good setting.
- Dithering trades banding for noise, and noise costs file size.
- Reducing to 64 or 128 colours often saves more than reducing frames.
So why does anyone still use GIF?
Because of where it is allowed. GIF plays as an image, which means it works in contexts that forbid or awkwardly handle video: email clients, many chat and forum inputs, documentation platforms, some CMS fields, and older wiki software. An MP4 in an email will not play; a GIF will.
It also autoplays silently and loops without any player controls, with no user gesture required. On mobile browsers, video autoplay is restricted by policy — video needs to be muted, inline and often explicitly permitted — while a GIF simply animates. For a small looping demonstration, that reliability is worth real bytes.
And it degrades to a still image everywhere, which no video format does.
The alternatives, and what each costs
Animated WebP is the closest replacement: it supports full colour, real transparency, and both lossy and lossless modes, at file sizes commonly 30-50% below an equivalent GIF. It is supported by every current browser. It is not accepted by many of the platforms that accept GIF, which is exactly the problem it fails to solve.
MP4 with H.264 is the size winner by a wide margin for anything photographic, and plays everywhere video is allowed. For a web page, a muted autoplaying looping MP4 is almost always the correct implementation of what people mean by 'a GIF' — same visual result, a fraction of the bandwidth. The cost is that it is a video element with the policies that come with it.
APNG deserves a mention as the honest answer for animations that need lossless quality and true alpha, such as UI animations on a transparent background. It is larger than WebP and supported in current browsers.
Making a GIF that is not enormous
If GIF is the requirement, the size levers in order of effectiveness are dimensions, duration, frame rate and palette — in that order, and it is not close.
Dimensions dominate because cost scales with area: halving the width and height quarters the pixel count. A 480-pixel-wide GIF is usually plenty, and 320 is fine for a UI demonstration. Duration is linear, and ruthless trimming to the two seconds that matter is the second-biggest win. Frame rate can usually drop to 10-15 fps before motion looks wrong, against 30 in the source. Palette reduction to 128 or 64 colours is the last lever and often costs less quality than expected.
One structural trick: a static background with a small animated region compresses far better than a moving camera, so stabilising or cropping to the moving part pays twice.
- Resize first — width 320-480 px is usually enough.
- Trim to only the seconds that matter.
- Drop to 10-15 fps.
- Reduce the palette to 128 or 64 colours.
- Crop to the moving region if the camera is static.
A short decision rule
If it is going on a web page you control, use a muted looping MP4 and stop thinking about it. If it is going into an email, a chat box, a forum post or a documentation platform that only takes images, use a GIF and optimise it hard. If it needs transparency and quality, use APNG or animated WebP and check the target accepts it.
The one combination to avoid is a long, full-screen, camera-moving GIF. That is the case where the format is at its absolute worst and something else is always available.