Every article about shrinking a GIF lists the same levers: reduce the colours, drop some frames, make it smaller, remove duplicate frames, run it through a compressor. The list is correct. What it never says is which one to reach for, and that turns out to matter far more than the list does — because the best lever for one GIF is worthless on another, and one of them can make your file bigger.
So we measured. Five GIFs covering the kinds of thing people actually animate, four levers applied one at a time with everything else held constant, and the same encoder for every variant so that the only thing changing is the lever.
The results
Each figure is the size of the result as a percentage change from that file's own baseline. Negative is smaller, which is what you want.
| GIF | Half the frames | 64 colours | 16 colours | Half size, smooth resize | Half size, nearest neighbour |
|---|---|---|---|---|---|
| Screen recording antialiased text, ~300 colours, 72.6 KB |
−32% | −40% | −54% | +126% | −47% |
| Photographic pan across a photo, 99.3 KB |
−46% | −21% | −36% | −58% | −62% |
| Noisy gradients worst case for the format, 2.11 MB |
−50% | −45% | −71% | −72% | −67% |
| Flat graphics diagram or logo style, 5 colours, 13.9 KB |
−27% | 0% | 0% | +232% | −45% |
| Small flat animation 128×128, 2 colours, 9.3 KB |
−44% | 0% | 0% | +305% | −54% |
Read down the columns rather than across, and the usual advice falls apart. Reducing to 16 colours is the best single lever on the screen recording and does nothing whatsoever to the two flat files. Resizing is the best lever on the photographic files and is catastrophic on the flat ones. Only dropping frames behaves predictably everywhere, and it is never the winner.
The one that goes backwards
Making an image smaller cannot make it bigger. That is true of the pixels and false of the file, and the gap between those two statements is where a 9 KB animation becomes a 38 KB one.
GIF compresses with LZW, which earns its savings from runs — long stretches of identical pixels, and repeated sequences it has seen before. A flat graphic is almost entirely runs, which is why a 60-frame animation can fit in 13.9 KB in the first place. Every GIF also carries a palette of at most 256 colours per frame.
Now resize it the way an image editor does by default, with a smooth filter. Smooth resampling averages neighbouring pixels, so along every edge it invents colours that were not in the image:
| GIF | Colours in the first frame | After a smooth half-size resize | After a nearest-neighbour resize |
|---|---|---|---|
| Small flat animation | 2 | 257 | 2 |
| Flat graphics | 5 | 78 | 4 |
| Screen recording | 255 | 582 | 182 |
| Photographic | 187 | 112 | 75 |
A two-colour image becomes a 257-colour image. Every run is now broken by a fringe of intermediate tones, LZW has almost nothing left to compress, and the file grows by 305% despite holding a quarter of the pixels.
Nearest-neighbour resizing picks one original pixel instead of averaging several, so the palette survives: 2 colours stay 2, and the same file loses 54% instead. On flat content the choice of resampling filter is worth a factor of six.
Notice the photographic row does the opposite — smooth resizing reduces its colour count from 187 to 112, because averaging smooths away noise. Same operation, opposite effect, and which one you get depends entirely on whether your GIF is made of flat areas or of texture.
The one that does nothing
“Reduce the number of colours” is the first item on every list, and on two of our five files it changed the size by exactly zero bytes. Not a little: zero.
The reason is uncomfortable once you see it. Those files contain 5 colours and 2 colours. Asking for 16 does not remove anything, because there was never anything to remove — the palette is already smaller than the target. The setting runs, the tool reports success, and the file is byte-for-byte what it was.
This is worth knowing because it is the most common wasted step. If a colour reduction did nothing to your GIF, it is not broken and you do not need a better compressor; your GIF simply did not have surplus colours. Check what it actually contains before reaching for that lever — and note that the file where colour reduction did win, the screen recording, wins precisely because antialiased text quietly fills the palette with hundreds of nearly identical greys.
The one that always works, and never wins
Dropping every other frame took between 27% and 50% off every single file. It is the only lever in the table with no surprises in it, because it is not really a compression decision: half the frames is half the data, adjusted for how similar neighbouring frames happened to be.
It is also the lever with the most visible cost. Going from 12 frames per second to 6 is obvious to anyone watching; dropping a photographic GIF from 256 colours to 64 often is not. So it is worth doing last rather than first, once the levers that cost less have been used.
What to do, by what is in your GIF
| If your GIF is… | Reach for | Do not bother with |
|---|---|---|
| A screen recording with text | Colour reduction — 16 colours took 54% off ours | Smooth resizing; it added 126% |
| Footage or anything photographic | Dimensions; either filter works, nearest was slightly better | Nothing is wasted here, but colours give the least |
| A logo, diagram or flat animation | Dimensions with nearest-neighbour, then frames | Colour reduction — it will change nothing at all |
And one cross-cutting piece of advice: if the GIF came from video and it is more than a second or two long, the format is the problem rather than the settings. GIF has no inter-frame compression worth the name, which is why our noisy test file is 2.11 MB for 40 frames of 400×300. The same content as a video file is smaller by an order of magnitude. GIF earns its place when you need something that plays inline anywhere with no player and no sound — not when you need it to be small.
How this was measured
Five GIFs: a screen recording with antialiased text, a pan across a photograph, a noisy gradient animation, a flat five-colour graphic and a two-colour 128×128 animation. Each lever was applied on its own, from the same source frames, and every variant was written by the same encoder with the same settings — including the baseline, so that the comparison is not against a file some other tool happened to produce.
The measuring instrument is Pillow, which is not our own encoder; the claims here are about the GIF format rather than about any tool. The colour counts are counts of distinct pixel values, taken before encoding. The script lives in our repository alongside the other measurement scripts, and the two findings worth repeating are both checkable in a minute: resize a two-colour GIF with a smooth filter and count the colours, and try reducing a five-colour GIF to sixteen.
One honest limit: these are five files, not a survey. The mechanisms behind the numbers — LZW rewarding runs, interpolation inventing colours, a palette that cannot shrink below what is in it — are properties of the format and will hold for your files too. The exact percentages will not.
Doing it
Compress GIF applies these levers in your browser and shows what each one did to the size, so you can see which of them your file responds to rather than guessing from a list. If you are starting from video, video to GIF lets you set the target size directly. And if the animation was never the point — if you only wanted one frame out of it — GIF to PNG and GIF to JPG take the first frame and hand back something a fraction of the size.