Compress GIF to a size you pick

Compress GIF files to a limit, not to a setting

Nobody wakes up wanting 64 colors. They want the file under the 8 MB a Discord upload will accept, or under the 2 MB an email gateway allows, or under whatever number the form in front of them is refusing to budge on. Every other GIF tool asks for the setting and reports the size afterwards. That is the easy direction and it is the wrong one: it makes you the search algorithm, running the same export four times with different numbers until one of them squeaks through.

Here you give the limit. The tool encodes, measures, adjusts, and encodes again until it lands under your number — and it shows you every attempt it made along the way, so the settings you end up with are not a black box. Search the term and the "people also search for" block is nothing but sizes: 256 KB, 100 KB, 512 KB, 1 MB, 5 MB, 10 MB. That is the actual question, so that is the input.

It is worth noting what the big names answer instead. The third result on this search is Adobe's page, and it is titled Resize Your GIF — dimensions, not bytes. Resizing is one of four levers, and it is deliberately the last one this tool reaches for, because a loss of resolution is the first thing anyone notices. Being handed the resize lever when you asked about file size is being answered a question you did not ask.

The four levers, cheapest first

A GIF has exactly four places where bytes can be given up, and they cost very different amounts of visible quality. The search spends them in order.

Colors first. A GIF stores each pixel as an index into a color table of at most 256 entries. Fewer distinct indexes mean longer runs of identical bytes, and longer runs are exactly what the LZW compressor inside the format packs well. On a real 240×180 animation, taking the palette from 256 colors down to 16 moved the file from 202 KB to 84 KB — a 58 % cut for a change that is close to invisible on flat illustration and shows as gentle banding on photographic content.

Then dithering, if you asked for it. This one surprises people, so the label on the checkbox says it out loud: dithering makes GIF filesbigger. Measured at 64 colors on the same animation, turning it on increased the file by 161 %. Dithering scatters the quantization error as fine noise to hide banding, and noise is precisely what a run-length-oriented compressor cannot pack. It is a quality feature with a byte cost, not a compression feature — so if you asked for it and the target will not fit with it on, the search switches it off and the receipt tells you it did.

Then frames. Dropping every second frame roughly halves the image data. It is visible as choppiness, which is why it sits behind a lock you can close. What it must never do is change how long the animation runs: when a frame is dropped, its delay is added to the frame that stays. A GIF that comes back sped up is not a compressed GIF, it is a broken one, and the receipt states the play time before and after so you can check.

Resolution last. Scaling to 75 %, 50 % or 35 % is enormously effective and enormously obvious, particularly on screen recordings where the whole point is text somebody has to read. It is the last resort, and when the search uses it you are told the new dimensions rather than being handed a quietly shrunken file.

Frame differencing is not on that list, because it is not a choice. Only the rectangle that changed between two frames is written, with unchanged pixels left transparent. It costs no visible quality at all, so it is simply always on.

Why your GIF barely shrinks

Frame differencing is also the best diagnostic in the format. Measured on two real files: on a screen recording, where a cursor moves across a static interface, it cut the output by 84 %. On full-frame camera motion, where no two consecutive pixels agree about anything, it cut it by 0.2 %.

That gap explains almost every "my GIF will not compress" complaint. GIF was designed for flat graphics with small moving regions. When a file resists every lever at once, it is usually because it is not really an animation — it is video wearing an animation's file extension, thirty complete photographs per second in a container built for logos. A twenty-second clip converted to GIF is often twenty times the size of the video it came from and looks worse. If that is what you have, no GIF compressor will save you and an honest one should say so instead of grinding down to a smear of blocks that technically meets the specification. The real fix is to leave the format: the same clip as MP4 or WebM will beat the best possible GIF by an order of magnitude, because those formats were built to describe motion and this one was not.

What this tool does not do

It does not upload anything. The decoder, the median-cut palette quantizer and the encoder are all JavaScript running in this tab, on a background thread so the page stays responsive while the search runs. There is no queue, no account, and no size limit beyond what your own device can hold in memory. It also means the GIF you are about to compress — which may well be a screen recording of something you should not be sending to a stranger's server — never leaves the machine.

It does not convert formats, crop, trim or add captions. It does not re-time your animation, ever. And it does not pretend a target is reachable when it is not: if the hardest settings it is willing to use still land above your number, it says so and tells you the size it actually managed, so you can decide between a looser limit, a shorter clip, or a different format entirely.

Changing your mind is the normal case

The first target is rarely the last one. Once a file is in, it stays decoded in memory on its own thread, so moving the slider and running again costs a couple of hundred milliseconds instead of several seconds — no re-reading the file, no re-decoding the frames. The presets are shortcuts to limits people actually hit, and the number field next to them exists because your limit might be 256 KB and no preset is ever going to guess that.