No matching tools
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.
Upload limits are almost always round numbers. This GIF size reducer does not fit a file to an exact number for you, but you can work out where to start in a minute. Below are starting settings for the targets people ask about most.
First work out how much you need to cut: divide the size you want by the size you have. Going from 12 MB to 5 MB means keeping about 42% of the bytes. File size falls roughly with pixel area, so scaling width and height to about 65% (0.65 × 0.65 ≈ 0.42) can get there on its own for many clips, and fewer colors plus lossy compression then give you a margin.
Realistic only for a short, small clip such as a sticker or a two to three second loop. Start with Smallest. If it is still over, the clip is too long or too large for the format at this size: trim it, or reduce the width in the advanced settings.
Start with Strong, which also resizes to 75%. Add frame dropping when the motion is slow or smooth enough to survive it.
Start with Strong. If it is still over, step down to Smallest or raise the lossy amount, and check gradients for banding at 64 colors.
Balanced is often enough for a short clip. For a full-width screen capture, resize to 75% first and compress after that.
Balanced fits most short clips. Anything over about ten seconds usually needs Strong with a resize. Past that, MP4 will fit with room to spare.
Light or Balanced fits most short recordings, which covers a free Discord account and GitHub per-file limit. Long full-width recordings need Strong.
These are starting points, not guarantees, because the result depends on the footage. After compressing, read the size shown for the result and change one setting at a time.
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
Every ShotEdit tool processes your images on your own device, so your files are never uploaded. The badge above each upload area confirms that the tool runs in your browser.
Processed in your browser · Never uploaded