GIF Compressor
Decodes a GIF in your browser and re-encodes it with fewer colours, fewer frames or fewer pixels, showing what each choice costs and saves.
This tool needs JavaScript: the GIF is decoded and re-encoded in your browser, and it is never uploaded.
A GIF holds at most 256. Dropping to 64 is usually invisible on a screen recording and saves a quarter of the file.
Pixels are the biggest lever: half the width is a quarter of the pixels.
2 keeps every other frame and doubles each remaining delay, so the animation runs at the same speed with half the data.
Working through the frames…
No GIF yet. The three things that make one smaller are fewer colours, fewer frames and fewer pixels, and this shows what each costs.
A GIF is big for three reasons: too many colours, too many frames, too many pixels. This lets you pull each lever and shows what it costs, with the original beside the result.
The work happens in your browser, which means the format had to be implemented here: a browser will show an animated GIF perfectly well and give you no way at its frames. Drawing one to a canvas paints whichever frame is on screen at that moment.
How to use
- Choose a .gif, or drop it on the box.
- Pull the levers. Colours first, then pixels, then frames.
- Compare the two panels, then download.
Changing a setting re-runs against the file you already chose.
Example
A 12-frame screen recording at 800 × 600:
Before · 800 × 600 · 12 frames · 2.4 MB
After · 400 × 300 · 6 frames · 64 colours · 480 KB
1.9 MB smaller, which is 80%Half the width is a quarter of the pixels, half the frames is half the data, and 64 colours is usually invisible on a screen recording. Those three together are where an 80 percent saving comes from; no one of them gets close.
Pitfalls
Dropping frames without lengthening the remaining ones speeds the animation up. Keeping one frame in two doubles each remaining delay here, so the timing stays as it was. Tools that forget this produce a GIF that plays at double speed.
Fewer colours shows on photographs, not on screen recordings. A screenshot or a UI recording has few colours to start with; a photograph banded down to 64 looks like a photograph banded down to 64.
A GIF of video should not be a GIF. Past a few seconds, an MP4 or a WebM is an order of magnitude smaller and plays better. The rule of thumb that has held for a decade: if it is longer than five seconds, convert it rather than optimise it.
The result can be larger than the original. Some GIFs use a palette per frame, which this rewrites into one shared palette; where the frames are genuinely different that costs more than it saves, and the tool says so rather than quietly handing you a bigger file.
Transparency survives, dithering does not. One palette slot is kept for transparency when any frame needs it. There is no dithering, which keeps flat areas flat and makes gradients band; for a gradient, scale rather than reduce colours.
Interlaced input is read, interlaced output is not written. Interlacing helped on dial-up and costs bytes now.
Very long GIFs are refused. Past 300 frames the decode is slower than anybody will wait for, and the answer at that length is a video anyway.
Compatibility
Everything happens in your browser: nothing is uploaded, nothing is stored.
The format is implemented here rather than imported. Decoding is the LZW variant GIF uses — codes least-significant-bit first, the code size growing one bit at a time, clear and end codes immediately above the palette — plus the frame composition a GIF needs, since a frame can be a patch on the one before it with its own disposal method. Encoding is the same LZW the other way, a median-cut palette across all the frames, and one global colour table, because a palette per frame is most of what makes an unoptimised GIF large.
Both directions are tested against each other and against files produced outside this repository: the test suite round-trips frames and delays, and the encoder’s output was opened and rendered by macOS’s own decoder rather than only by this one.
Scaling goes through a canvas, which is the one part the browser does better than any code here.