GIF Compressor
Name the size limit. It compresses, measures the real file and steps down until it lands under — or says so and keeps the smallest result.
Runs entirely in your browser. Your videos never leave this device.
This GIF compressor shrinks a GIF under a size you name — 20 MB for Discord, 256 KB for an emoji, or any KB or MB figure — on your device, nothing uploaded. It works a GIF’s three real levers: every frame is re-encoded with a palette optimised for the whole clip (up to 256 colours), and frame rate and dimensions are lowered only as far as the target needs, measuring the real file after every pass, up to five. Savings are typically 30–65 % and vary widely with content. Shrinking a GIF always discards something — colours, frames or pixels — and some clips cannot reach a tiny target. When yours can’t, it says so, keeps the smallest result and offers a silent MP4 (usually 85–95 % smaller). No watermark, no signup, no artificial file-size cap.
How does a GIF compressor reduce the file size of a GIF?
A GIF compressor makes a GIF smaller by cutting the three things that decide its size: the number of colours in the palette, the frames per second and the pixel dimensions. A GIF stores every frame as a complete indexed image with nothing like a video codec’s motion prediction, so 10 seconds of 1080p animation runs to tens of megabytes — we measured 1.8–8.6 MB for a single second at 1080p and 15 fps, depending on the footage — and a re-encode that changes none of those three comes out at about the same size — there is no free “optimise” button. Measured on our engine, cutting the palette from 256 to 128 colours removes 16–27 %, dropping the frame rate from 15 to 10 fps removes about 31 %, scaling the width to 75 % removes 28–37 %, and all three together remove 61–66 % — though two clips with identical settings can differ 5× in size, because flat screen recordings compress far better than gradient-heavy footage. This tool applies the levers in that order, starting at the step its size prediction says should fit, re-encoding every frame with a palette computed for your whole clip and ordered dithering, and measures the real output after every pass, up to five, until one lands under the target you typed — or tells you it can’t and keeps the smallest result. If the destination accepts video at all — Discord, Slack and X do — converting the GIF to a silent H.264 MP4 is usually 85–95 % smaller than the GIF, because a video codec stores mostly what changes between frames.
The facts that matter
| Target size | Any KB or MB figure, or a preset chip — 20 MB Discord upload · 15 MB X web · 10 MB GitHub · 8 MB GIPHY (its recommended size) · 5 MB X mobile · 1 MB · 512 KB Twitch emote · 256 KB Discord emoji · 128 KB Slack emoji; frame caps built in (X 350, Twitch 60, Slack 50) — limits read from each platform’s help pages, Sep 2026 |
|---|---|
| How it lands under | Predicts a starting point from the file size, encodes, measures the real file, steps down — colours first, then frame rate, then dimensions — up to 5 passes, stopping at the first that fits; if none does, it says so, keeps the smallest result, suggests a shorter loop and offers the MP4 on the same card — never a larger file silently |
| Method | Every frame re-encoded with one palette computed for the whole clip (up to 256 colours, one slot reserved for transparency) and ordered dithering; only the region that changes is rewritten per frame; colours are re-quantised, so some detail is discarded. Or set the levers yourself: 256 / 128 / 64 / 32 colours, 15 / 10 / 8 / 5 fps or as is, 480 / 320 / 240 / 160 px or as is |
| Typical savings | 30–65 % as a GIF, strongly content-dependent — all three levers together removed 61–66 % on our engine; two clips at the same settings can differ 5× (flat screen recordings small, gradient-heavy video large); a re-encode with no lever changed saves ±0 % |
| Output | GIF; or one-click silent H.264 MP4 from the result card, made from your original GIF — usually 85–95 % smaller, plays inline on Discord, Slack and X |
| Speed & batch | Typically 2–6 s per pass for 2–9 MB GIFs on a laptop, single-threaded; queue many files, processed one after another, each with an instant header readout (dimensions, frames, duration, fps, size) and its own download |
| Limits | No watermark, no signup, no artificial size cap — browser memory (~1–2 GB) is the practical ceiling |
| Privacy | Processed entirely on your device — FFmpeg compiled to WebAssembly, ~32 MB downloaded once and cached; nothing uploads, works offline after the first load |
Get a better result
- A “60 fps GIF” plays at 10 fps. Frame delays are stored in whole hundredths of a second, and browsers treat any delay under 2 cs as 10 cs — so a clip exported at 60 fps shows every frame at 10 fps, six times slower than intended, carrying six times the frames a real-time 10 fps export would; 50 fps (a 2 cs delay) is the most a GIF can play. The header readout on each file applies the same rule, so the symptom is visible before you compress: 10 fps and a playback duration far longer than your clip. Lowering the frame rate here can only thin the frames further, not restore the speed — go back to the source video and export at 15 fps or lower (the video-to-GIF tool on this site tops out at 25 fps).
- For a custom emoji or emote, prepare the clip before you compress it. The emoji presets — 256 KB Discord, 128 KB Slack, 512 KB Twitch — start at 128 px wide (112 px for Twitch) with 64 colours, and shrinking a 480 px source to 128 px already sheds over 90 % of its pixels, so crop to the subject in an image editor first: at 128 px, every column spent on empty margin is a column the subject does not get. Then trim to the loop point — Slack caps emoji at 50 frames and Twitch emotes at 60, the presets lower the frame rate to fit but will not go below 5 fps, and a 4-second clip at 15 fps is already 60 frames — and let the size mode take care of the colours.
- Flat UI screen recordings and camera footage want different levers. A screen recording is the easy case — big regions of identical colour and long stretches where nothing moves are what the clip-wide palette and changed-region encoding exploit — so record only the window that matters, take the colour cut first (256→64 removed 34–49 % on our engine, and text stays crisp because it used few colours anyway) and drop to 10 fps, where cursor movement still reads. On gradient-heavy footage, fewer colours means visible banding in skies and skin, so when you set the levers yourself reach for frame rate (15→10 fps removed about 31 %) and width (three-quarters width removed 28–37 %) before colours — or take the MP4. With identical settings, two clips can differ 5× in size.
- If the GIF is going on a web page you control, ship the MP4 rather than the GIF. Lighthouse flags any animated GIF over 100 KiB (verified Sep 2026), and a muted, looping, inline-playing video element behaves like a GIF at usually 85–95 % less weight — the “Convert to MP4” button on the result card produces that file from your original. Keep a real GIF only where an image tag is the only thing that will play: a README, an email, a CMS that refuses video.
- Sending a GIF by email? Gmail and Outlook.com accept attachments up to 25 MB, but classic desktop Outlook shows only the first frame unless the recipient has enabled animations (verified Sep 2026). Make the first frame stand on its own — a title card or the finished state, not a fade-in from black — and keep the file small enough to load before the reader scrolls past it.
Frequently asked questions
How can I compress a GIF to under 20 MB for Discord?
Pick the 20 MB Discord preset (or type 20 MB), drop the GIF in, and the tool compresses it, measures the real file and steps down — colours first, then frame rate, then dimensions — for up to five passes, until one lands under 20 MB or the passes run out. Discord’s free upload limit is 20 MB, raised from 10 MB in August 2026; Nitro Basic allows 50 MB and Nitro 500 MB (verified Sep 2026), and most other tools and guides still quote the old 8 or 10 MB, so you may be compressing harder than you need to. If your GIF is several times over the limit, the GIF route means heavy colour and frame-rate cuts; the “Convert to MP4” button on the result card gives a silent H.264 file that is usually 85–95 % smaller and plays inline in Discord. If even five passes can’t get under, the tool says so and keeps the smallest result rather than pretending.
How do I make a GIF smaller than 512 KB, 256 KB or 128 KB for an emoji or emote?
Pick the matching preset — 512 KB Twitch emote, 256 KB Discord emoji (Microsoft Teams has the same 256 KB limit), 128 KB Slack emoji — and the tool starts at 128 px wide (112 px for Twitch) with 64 colours, lowers the frame rate so the clip fits the platform’s frame cap (Slack 50, Twitch 60), then steps colours, frame rate and size down until a pass lands under the limit or five passes are spent. The rules, verified Sep 2026: Discord custom emoji must be under 256 KB and Discord publishes no pixel rule (the 128×128 figure is folklore); Teams emoji under 256 KB; Slack under 128 KB and at most 50 frames; Twitch animated emotes at most 512 KB and 60 frames. The frame cap is the hard part for a long clip — 50 frames spread over 10 seconds is 5 fps, the lowest this tool goes — so if your loop is longer than that it tells you to trim it shorter first, and if the size cannot be reached it says so and keeps the smallest result. Discord stickers are a different thing entirely: they take APNG at 512 KB and 320×320, not GIF.
Why did my GIF get bigger after compressing it?
Because the tool re-encoded it in a way that cost more bytes than it saved — usually by coalescing frames into full images (undoing the original’s frame-difference optimisation), by writing a separate palette for every frame, or by applying heavy dithering that fills flat areas with noise. A GIF has no quality dial to turn down; its size is set by colours, frame rate, dimensions and how well unchanged pixels are skipped, so a “compressor” that changes none of those gains nothing worth having — and some tools hand you the larger file without comment. This one never returns a larger file silently: if a re-encode would be bigger than your original, you get the original back and the result card says so, and if the file is already under a plain size target it is returned unchanged and labelled (the emoji presets still apply their width and frame caps). To actually get smaller, one of the three levers has to move.
Is there a lossless way to compress a GIF?
No — not one that shrinks the file meaningfully. The tricks that discard nothing — rewriting only the region that changes between frames and marking the rest transparent — are already on in this tool’s encoder, and on our test clips a re-encode with no lever changed lands at ±0 %, so there is no free saving hidden in the file. Every method that actually removes bytes discards something you can see — colours, frames or pixels — and the palette re-quantisation this tool does is no exception; what a palette computed for your specific clip buys you is that the 256 slots go to the colours your clip actually uses rather than a generic set. The one saving that costs no visible quality is cropping away dead margins, which this tool does not do (any image editor can) — do that before you drop the file here. If the destination accepts video, a silent H.264 MP4 is usually 85–95 % smaller and keeps more of the original’s colour than a GIF squeezed to 64 colours.
Why is a GIF 10–50× bigger than the MP4 it came from?
Because a GIF stores every frame as a complete indexed image with no prediction between frames, while H.264 stores one full frame and then mostly the differences from the frames around it. Ten seconds of 1080p animation as a GIF runs to tens of megabytes — we measured 1.8–8.6 MB for a single second at 1080p and 15 fps — while the same clip as MP4 is a small fraction of that, and the GIF looks worse while being bigger, because its palette is limited to 256 colours. That is also why the levers you control are colours, frames and pixels — there is little else to squeeze. So the result card offers a one-click conversion: the silent H.264 file is usually 85–95 % smaller (87–96 % on our test clips) and plays inline on Discord, Slack and X. The reasons to keep a GIF are destinations that require the format — custom emoji, GitHub READMEs, email.
Do fewer colours or dithering make a GIF bigger or smaller?
Fewer colours make it smaller; dithering usually makes it bigger for the same palette. On our engine, going from 256 to 128 colours removes 16–27 % and 256 to 64 removes 34–49 %, because a smaller palette creates longer runs of identical pixels, which compress well; the cost is banding, most visible in skies, skin and soft shading and least visible at emoji size, which is why the emoji presets start straight at 64 colours. Dithering does the opposite: it scatters alternating pixels to fake the shades you removed, which looks smoother but is what compresses badly — heavy error-diffusion dithering can eat a large part of what the colour cut saved. This tool builds one palette for the whole clip (255 colours plus one transparent slot for unchanged pixels) and uses ordered dithering, whose regular pattern is usually kinder to GIF compression than error diffusion — usually, not always, which is why the size mode measures every pass instead of trusting a prediction.
Discord says my GIF is under the limit but still rejects it — why?
Usually because you are hitting a different limit than the one you checked. Discord’s 20 MB free upload cap applies to attachments; custom emoji must be under 256 KB, and stickers take APNG (512 KB, 320×320), not GIF, so a file that is fine in chat will be refused as an emoji or sticker (verified Sep 2026). Second, units: “256 KB” can mean 256,000 bytes or 262,144, and file managers disagree too — Windows Explorer counts 1 KB as 1,024 bytes, so a file it shows as 255 KB is 261,120 bytes, over a 256,000-byte line; this tool also counts 1 KB as 1,024 bytes, so type a target a few percent below the cap — 245 KB rather than 256 — and it clears on either reading. Third, uploading a GIF as an avatar opens a cropper, and applying the crop re-encodes the image and can push it back over — press Skip to upload the file untouched. And a GIF that uploads but sits still is not a failed upload: that viewer has Discord’s GIF autoplay setting switched off.
Which platforms convert my GIF to video anyway, and which need a real GIF?
Telegram, X, Facebook and Mastodon (up to 16 MB) convert an uploaded GIF to MP4 on their servers, and Shopify turns it into an animated WebP; WhatsApp and Reddit are widely reported to convert as well, though we could not confirm it on an official page (everything else here verified Sep 2026). On those platforms a GIF only costs you upload time and a second round of re-encoding — you can send the MP4 from the result card instead, usually 85–95 % smaller. A real GIF is needed where the format is enforced: custom emoji on Discord (under 256 KB), Slack (under 128 KB, ≤ 50 frames) and Teams (under 256 KB); Twitch emotes (≤ 512 KB, ≤ 60 frames); GitHub, which takes images and GIFs up to 10 MB; Notion at 5 MB per file on the free plan; GIF libraries — GIPHY accepts up to 100 MB and 15 s but recommends ≤ 8 MB, 480p and under 200 frames, Tenor up to 14 s; and email, where Gmail and Outlook.com allow 25 MB attachments. X is the odd one out: it takes GIFs up to 15 MB on the web and 5 MB on mobile, ≤ 350 frames (an API limit), and then converts them anyway.
Is there a file size limit, and is my GIF uploaded anywhere?
No artificial limit and no upload. The engine — FFmpeg compiled to WebAssembly, about 32 MB — downloads once, is cached, and then every frame is decoded, re-palettised and re-encoded on your device; you can check it in the browser’s network tab while compressing — after the engine loads, no request carries your file, and the page keeps working offline. The practical ceiling is your browser’s memory, roughly 1–2 GB, which is a very large GIF. The trade-off is that your device does the work: a pass on a 2–9 MB GIF typically takes 2–6 seconds on a laptop, a size-mode run is at most five passes, and a batch is processed one file after another, so a long queue takes proportionally longer. No watermark, no signup.