How this GIF compressor works
Drop a GIF, choose what you can spare, download the smaller one. Your browser decodes the animation, rebuilds it and writes new GIF bytes inside the tab. The file never becomes a network request.
A GIF holds at most 256 colors and one palette index per pixel, so a compressor has three things it can spend: the size of that palette, the number of pixels, and the number of frames. Each button spends one of them.
Whichever you pick, the encoder also does the housekeeping a good GIF writer does. It compares every frame against the one before it, marks the pixels that held still as transparent so they cost almost nothing, and crops the frame down to the rectangle that actually moved. A wiped-and-redrawn frame gets its own disposal flag so the animation cannot ghost.
Measured over 28 animated GIFs from Wikimedia Commons, 25 KB to 9.0 MB, 2 frames to 416:
- Flatter colors took a median of 36% off. Six of the 28 came out bigger than they went in, and the tool handed those back untouched.
- Half size took a median of 69% off and won on all 28. Its worst case still came out 17% smaller.
- Fewer frames took a median of 49% off, and grew 2 of the 28.
The frame diffing and the cropping on their own, with all 256 colors left alone, moved those same files by a median of 1%. Most GIFs you find on the web have already been through gifsicle or something like it, so that half of the work was done before you got the file. The palette is what is left to spend, which is why the default setting spends it.
Two of those files, in full. Newton's cradle runs 308,156 bytes at 480 × 360 over 36 frames, and comes out at 185,093 bytes on Flatter colors or 62,070 on Half size. A 7.3 MB animation of the Hayabusa2 orbit, 560 × 420 across 416 frames, lands at 1,280,735 bytes after about seven seconds of work.
When you'd reach for it
- A chat app or a mail server turned it away. Halving the width and height is the fastest route under a cap, and it is the only setting here that got smaller on every file tested.
- A README or a docs page loads slowly. Flat-color animation is where 32 shades cost nothing: a 600 × 600 clock of 120,384 bytes came out at 65,909 on the default setting.
- A forum or wiki avatar has a byte limit. Small canvas, few colors, and Flatter colors usually clears it on its own.
- You want the same clip, shorter in bytes, same length in seconds. Fewer frames merges each dropped frame's delay into the frame beside it, so a 4-second loop is still 4 seconds long.
- Nobody optimized it on the way to you. Two of the test files gave up 67% and 50% to the frame diffing alone, before any color was touched. Those are the files this page is best on.
What this tool cannot do
It cannot beat a GIF that has already been squeezed. Six of the 28 test files came back bigger on the default setting, so the tool returned the original and the size row says so. A 307 × 230 animation of 25,222 bytes was one of them: Flatter colors produced 32,078 bytes, 27% worse. Fewer frames got it to 15,567. When one setting refuses, try the next one.
You cannot ask for a target size. No field takes "get me under 8 MB". You choose what to give up and read what it cost.
256 colors is the format's ceiling, and this tool starts below it. A GIF has never held more than 256 colors per frame. The default drops that to 32, so skies, skin and any smooth gradient band into visible steps. A photograph shows it worst.
Nothing is dithered. Each pixel snaps to the nearest color in the new palette, which gives clean flat areas and hard banding. Dithering would soften the bands and add noise that costs more bytes than the bands save.
Half size means exactly half. There is no box to type 480 into. A 1000 × 750 GIF becomes 500 × 375.
Video footage has nothing for the frame diffing to grab. When every pixel changes a little every frame, marking still pixels as transparent finds almost none. Those files rely on the palette and the resize alone.
The animation comes back as it went in, minus what you spent. No cropping, no reversing, no reordering, no pulling out a single frame, no speed change.
500 frames, and about 150 million pixels across the whole animation. A 560 × 420 GIF of 416 frames sits just under that and takes around seven seconds. Past the limit the tool says so rather than freezing your tab.
One GIF per run. Two long animations back to back would leave you watching a progress bar for half a minute with nothing to show for either.
Switching format would beat all of this, and this page will not do it. The same clip as an MP4 or a WebP runs a tenth of the size with full color. If whatever you are uploading to accepts video, send video.
Frequently asked questions
Which setting should I start with?
The one already selected. Flatter colors keeps every frame and every pixel, so nothing about the animation changes except how many shades it draws with. If the result is not small enough, or if the file comes back untouched, move to Half size, which won on all 28 test files.
Why did my GIF come back the same size?
Because every setting the tool tried produced something larger than what you gave it, so it handed your file back rather than downgrading it. That happens on files a real optimizer has already been through. Pick a different setting.
Does it still loop?
Yes. The looping block is read out of your file and written back with the same count, so a GIF that loops forever keeps looping forever and one that plays twice still plays twice. The test suite checks both directions on every run.
Does dropping frames make the animation shorter?
No. Each surviving frame takes on the delay of the frame it replaced. Six frames at 0.05 seconds become three frames at 0.1 seconds, and both run for 0.3 seconds. The motion gets steppier and the clip ends when it always did.
My GIF has a transparent background. Does that survive?
Yes. Transparent pixels stay transparent, and a frame that turns painted pixels see-through gets a disposal flag telling the browser to clear the canvas first. Without that flag those pixels would keep showing whatever was under them.
Why does the result look banded?
Because 32 colors cannot describe a gradient. The quantizer picks the 32 shades that fit your animation best and rounds every pixel to the nearest one, which leaves visible steps where the original had a smooth ramp. Half size keeps 128 colors and bands far less.
How long does it take?
A 480 × 360 animation of 36 frames took 150 ms. A 9.0 MB, 1000 × 750, 40-frame clip took about 1.5 seconds on Half size. The 416-frame file took nearly seven. Those come from the test runner on a desktop, and a phone will be several times slower, because the animation gets decoded twice: once to sample colors from across the whole clip, once to write it back out.
Is my GIF uploaded anywhere?
No. Your first click fetches the compressor code from this site, and the file itself stays in the tab. There is no upload step and no queue to wait in.
Can I make a GIF smaller by cutting it short instead?
Not on this page. This one takes the animation you give it and gives the same animation back. Trimming belongs to a tool that can show you the timeline.