I spent an afternoon compressing the demo GIFs on our docs site. Some dropped to a quarter of their size. One came back bigger than the original.
Same tool. Same preset. The difference wasn't the tool — it was the footage.
The floor is set the moment you import
GIF has two hard constraints, and neither of them is the quality slider.
Constraint one: 256 colours per frame. Think of it as a box of 256 pencils. However many shades your footage needs, you only get to pick from those.
Constraint two: frames are stored as differences. This one is closer to drawing a flipbook. If this page is identical to the last page except for one corner, you only draw that corner. GIF encoders do exactly that — pixels that didn't change aren't stored again.
So the amount of space you can win comes down to one thing: how much of the frame stands still. That's not something a slider can influence.
Three runs, three outcomes
I generated the test footage myself so I could control the variables. The tool was ImgIng's animation workshop (imging.ai) — I picked it because the frame splitting and re-encoding happen in the browser, and the footage was screen recordings of an internal console I'd rather not upload. I kept the Network tab open the whole time: three files, a dozen exports, not a single POST request. You can reproduce that check yourself in about a minute.
Run 1 — screen recording. 720×405, 36 frames. A fake console UI where six list rows never move and only a progress bar and a cursor animate.
79.8 KB → 21.3 KB. The tool auto-selected 64 colours.
It compresses because almost everything stands still. Six rows unchanged across 36 frames means the encoder skips them entirely. And flat UI palettes don't need 256 colours — 64 is invisible to the eye here.
Run 2 — full-frame noise. 480×320, 24 frames of regenerated random noise. Almost no pixel matches its neighbour in time.
2.62 MB → 2.63 MB. Auto-selected 256 colours. The UI said it out loud: "no size reduction — GIF isn't suited to this kind of footage, WEBP is usually smaller and sharper."
Both levers are dead here. Nothing stands still, so differencing wins nothing. The palette is already maxed out, so reducing colours only costs you dithering.
Worth noting the product behaviour: when it can't shrink the file it keeps your original and tells you, instead of handing you something larger. That's not universal — "compressed to something bigger, shipped anyway" is a real implementation out there.
Run 3 — an already-optimised spinner. 120×120, 8 frames, three colours.
2.0 KB → 1.5 KB. Auto-selected 16 colours.
Interesting because it was already tiny and still gave up a quarter, purely by shrinking the palette from a padded 256 entries down to the 16 actually in use. But that's the end of the road — anything further means smaller dimensions, fewer frames, or visible quality loss. That isn't compression, that's editing.
Three traps, in the order you'll meet them
Trap 1: running video-like footage through GIF. Video exports, live action, gradients, noise. These aren't hard to compress — they're in the wrong container. The 256-colour ceiling is a structural mismatch, not a tuning problem.
Trap 2: re-compressing something already optimised. Downloaded reaction GIFs, spinners shipped with component libraries — most have already been palette-reduced and differenced. You'll scrape off a thin layer, not half.
A quick sanity check: divide file size by width × height × frames. Well under 1 byte per pixel means it's already done.
Trap 3: assuming a new container equals a smaller file. What makes animated WebP smaller than GIF is that it has no 256-colour ceiling and can encode lossily. That comes from re-encoding, not from rewrapping.
Three things to check before you start
- Classify the footage. UI recordings, icon animations, flat-colour art → worth compressing, usually by a lot. Live action, gradients, noise → change format instead.
- Check whether it's already optimised. Use the bytes-per-pixel estimate above.
- Decide whether you're allowed to change dimensions or frame rate. If the footage itself won't compress, that's the only lever left — and it changes the content, so confirm the use case tolerates it.
Limits
All three numbers come from synthetic footage I built to sit at the extremes, so don't use them to predict what your GIF will do. Compression outcomes depend entirely on the source; the same footage at a different size behaves differently. What they do show is the mechanism: standing-still pixels and palette size set the ceiling, and parameters only operate underneath it.
Also worth saying plainly: "it didn't get smaller" is sometimes the correct answer. A tool that tells you so and keeps your original is being more honest than one that hands you a larger file.
