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.

What a GIF actually is

GIF

Full name	Graphics Interchange Format
Extension	.gif
Format type	Lossless raster image, 256 colors, animatable
MIME type	image/gif

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 files bigger. 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. Where the destination accepts it, the same animation as a WebP is the least destructive escape of all — every frame kept, written lossless, transparency intact, and measured at about a tenth of the GIF — so it is worth ruling in before you start trading colors away here. If the GIF has to stay a GIF and you still have the video it came from, the better move is to start over from that source and choose the frame rate and the seconds on the way in. The same applies when the original was an animated WebP: redoing the conversion with fewer colors or a smaller width beats squeezing a GIF that was already generated at full size — and the same is true when the animation was assembled here in the first place, where rebuilding it from the stills lets you drop half the frames before a single byte is written. Every frame you never encode is one no compressor has to rescue afterward.

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.

That last point is worth testing against the alternatives rather than believing. The big conversion sites take the opposite approach by design, and their terms describe it plainly enough once you read them: what FreeConvert's policy actually says works through the retention window, the third parties involved, and which of the promises on the marketing page survive contact with the legal one.

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.

And nothing to obtain beforehand

The desktop answers to this are Gifsicle at a command prompt, ffmpeg with a palette filter, or an export dialog in an editor. All three are better than they get credit for, and all three assume a computer you administer. The animation that needs shrinking is usually somewhere else: a laptop signed out for the afternoon, a school machine, a work desktop where the installer ends in a dialog telling you to ask somebody, a tablet with no command prompt to type into. The message it is meant to go into is due now, not once a request has been approved.

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.