How to compress a GIF
- Drop your GIF on the box above, or click it to pick a file (up to 50 MB).
- The tool compresses it straight away with the default settings — full size, all frames, Medium compression — and shows the new size next to the original.
- Still too big? Lower Scale first, then set Frames kept to Half, then Strong compression. Each change re-runs automatically.
- Compare the two previews. When the compressed one looks right, click Download GIF.
Why GIF files get so large
GIF dates from 1987, and it stores animation as a stack of pictures. Each picture can use at most 256 colours, and each is compressed on its own with LZW — a lossless method that works well on flat areas of colour and badly on anything with gradients, shadows or noise. There is no motion prediction of the kind MP4 uses: if a cursor moves across an otherwise still screen, a naïve encoder stores the whole screen again.
The format does allow something better, and this compressor uses it. A frame can mark pixels as transparent, meaning “keep whatever the previous frame showed here”. Long runs of transparent pixels compress to almost nothing, so a screen recording where only a menu and a cursor move can store just those regions. Two common myths are worth correcting while we’re here: GIFs do not need a separate colour table for every frame (a single shared table is normal), and they can store only what changed between frames — plenty of encoders simply don’t bother.
What each setting does
Scale
Resizes every frame. Size falls roughly with the pixel count, so 50% scale leaves a quarter of the pixels. It is the most reliable lever, but it is also the one that blurs small UI text first — zoom into the preview and check menus and labels before you settle on 50% or 33%.
Colours
The palette size for each frame. Fewer colours can mean slightly smaller LZW output, but on screen recordings the effect is small and unpredictable: going from 256 to 128 saved 6–10% on three of our test GIFs and made the fourth 15% larger, while gradients start to band. Leave it at 256 unless you have tried everything else.
Frames kept
Half writes every second frame and Third every third. Each kept frame takes over the display time of the frames dropped after it, so the GIF lasts just as long. Fine for UI walkthroughs; fast cursor movement will look choppier.
Compression
Decides how different a pixel must be from what is already on screen before it gets redrawn. Off only skips pixels that are exactly unchanged. Light, Medium and Strong also skip pixels that changed by a little — invisible on flat UI, but slow-moving gradients can show faint blotches at Strong.
How much smaller? Measured on real screen recordings
We ran the compressor on four GIFs: three made from our own raw screen captures (a 5-second and a 15-second desktop clip at 1280 px wide, and a 28-second iPhone clip at 480 px, all 15 fps) plus one real-world screen-recording GIF. Savings versus the original file:
| Setting | Desktop 5 s (4.2 MB) | Desktop 15 s (18.9 MB) | iPhone 28 s (33.2 MB) | Real-world GIF (4.7 MB) |
|---|---|---|---|---|
| Default (100%, Medium) | −71% | −36% | −25% | −27% |
| Scale 75% | −34% | −36% | −32% | −17% |
| Scale 50% | −62% | −67% | −66% | −51% |
| Frames kept: Half | −36% | −42% | −46% | −16% |
| 75% + Medium | −85% | −64% | −54% | −53% |
The short desktop clip is mostly still — a headline and a cursor — so Medium compression alone removes 71%. The real-world GIF had already been through a good encoder, so there was less to win: re-encoding it untouched made it 22% larger, and only Scale brought big savings. The longer clips scroll and animate, which leaves less to skip, and scale does more of the work. That pattern holds generally: the more of the screen moves, the more you need Scale or fewer frames.
GIF or MP4?
For the same clip, an H.264 MP4 is usually many times smaller than even a well-compressed GIF, and it keeps millions of colours instead of 256. If you are posting somewhere that plays video — X, LinkedIn, Slack, a landing page — MP4 is the better file. GIF still earns its place wherever only images are allowed: GitHub READMEs and issues, most documentation tools, email newsletters, and older chat apps. That is exactly where file-size limits bite, and where a compressor helps.
If you are making the GIF from a screen recording in the first place, choosing the size and frame rate at export time beats compressing afterwards: a 12 fps GIF exported at the final width never carries the extra frames and pixels you would otherwise throw away here.
