Shrink an animated GIF until it fits an upload limit, without sending the file anywhere. Compression runs locally with gifsicle compiled to WebAssembly.
A GIF stores every frame as its own palette-indexed image. A three second screen recording at 15 frames per second is 45 stored images, so file size grows with duration, frame rate, and pixel area all at once. That is why a short clip that would be a 400 KB MP4 becomes a 6 MB GIF.
GIF also has no real interframe compression beyond storing only the changed rectangle of each frame. Once a recording has gradients, dithering, or camera motion, almost every pixel changes between frames and that optimisation stops helping.
That is what a GIF compressor is actually doing: it cannot switch the file to a better codec, so it reduces the palette, smooths away the noise that defeats run-length compression, shrinks the frames, or removes some of them. Every one of those is a visible trade, which is why this tool exposes them individually instead of hiding everything behind one slider.
Four levers change file size, and they fail in different ways. Knowing which one to reach for saves a lot of trial and error.
Allows nearby pixels to be rounded to the same palette entry so runs compress better. This is the single biggest win on GIFs converted from video: in our tests a 228 KB clip dropped a further 7% at lossy 30, 15% at lossy 80, and 25% at lossy 200. On flat interface recordings it does almost nothing, because there is no dithering noise to smooth away.
Reduces the palette from 256 down to as few as 2. Photographic and gradient-heavy GIFs show banding quickly; flat UI screenshots and line art often survive 64 or even 32 colors with no visible difference.
Scales every frame down. File size falls roughly with pixel area, so 75% width is about half the pixels. This is usually the most reliable reduction when a GIF must hit a hard limit.
Removes every second or third frame. Size falls close to proportionally, and motion becomes choppier. Good for long screen recordings, bad for short reaction clips where the timing is the point.
The whole process runs in this browser tab. Nothing is uploaded, and there is no queue to wait in.
If a GIF has already been through a compressor, the easy savings are gone. Pushing lossy higher will keep shrinking it, but at some point the dithering artefacts become visible before the file gets meaningfully smaller. A good check is to compare the before and after previews at full size rather than trusting the percentage alone.
Short clips with very few colors are another case where little happens. A two colour loading spinner is already close to the smallest a GIF can be, and the palette and lossy controls have almost nothing left to remove.
Very long or very large recordings hit a harder limit. A 20 second full-width screen capture will not reach a 5 MB chat limit at acceptable quality no matter which settings you pick. For that case a video is the right format — MP4 will be a fraction of the size at better quality.
A useful order of operations when you compress a GIF against a hard limit: resize first, because it is the most predictable reduction and it costs the least visible quality per kilobyte saved. Then raise the lossy amount until artefacts start showing in flat areas. Reduce colors next, watching gradients for banding. Drop frames last, since choppy motion is usually the first thing a viewer notices.
Most people compress a GIF because something refused to accept it. These are the limits worth aiming at, and what usually gets a screen recording under them.
| Slack | Uploads fine, but anything over about 2 MB is slow to load in a busy channel | Balanced is usually enough for a short clip; resize to 75% for a full-width capture. |
|---|---|---|
| Discord | 10 MB on a free account | Long recordings need Strong plus a resize. Discord also accepts MP4, which is far smaller. |
| Converts GIFs to video, but very large files fail to send | Smallest, or drop every second frame if the motion still reads clearly. | |
| Commonly 20-25 MB for the whole message | Compress the GIF, and consider linking to it instead if it is the main attachment. | |
| GitHub issues and pull requests | 10 MB per file | Balanced with 128 colors keeps UI recordings readable while comfortably fitting. |
| A web page | No hard limit, but GIF hurts Core Web Vitals quickly | Compress for the short term, then switch the asset to MP4 or WebP when you can. |
If a GIF still will not fit after Smallest, the clip is too long for the format. Converting it to video is the honest answer — the same recording as MP4 is routinely five to ten times smaller than a compressed GIF at better quality.
Yes. Every frame, the frame timing, and the loop setting are kept. Frames are only removed if you explicitly turn on frame dropping.
Yes. Transparent areas stay transparent, so a GIF sticker or logo animation will still sit correctly on any background.
There is no fixed limit. Compression happens in your browser, so the practical ceiling is your device memory. Very large GIFs simply take longer.
No. The compressor is gifsicle compiled to WebAssembly and it runs inside this page. The file never leaves your device, which matters for unreleased product recordings and anything containing customer data.
No. The download is the compressed GIF and nothing else, with no account required.
Rarely by much. Palette reduction and lossy smoothing are not cumulative in a useful way, so a second pass at the same settings returns almost the same file. Change a setting instead — resize the frames or lower the color count — rather than re-running the same compression.
The GIF was probably already optimised. Try a stronger level, lower the color count, resize the frames, or drop every second frame. If it still will not fit, the clip is likely too long for the GIF format at that size.
Working with still images instead? These run in the browser too. image compressor · image converter
Your photos are never uploaded to our servers. All image editing happens locally in your browser for complete privacy protection and security.