How to Make a GIF Under 10 MB for Discord and Slack (2026 Limits)
June 12, 2026
10 MB is the number that matters. That’s Discord’s upload cap for free accounts, and it’s the wall most people hit the first time they try to share a screen recording as a GIF. Slack’s limit is far more generous on paper, but there are good reasons to stay small there too.
This guide covers the current limits (verified, with sources), why GIFs balloon in the first place, and a concrete workflow that reliably gets a typical screen recording under 10 MB without turning it into a smudge.
The actual limits in 2026
Discord’s free limit has bounced around. It went from 8 MB to 25 MB in April 2023, then back down to 10 MB in September 2024, with Discord citing storage costs. It has stayed at 10 MB since.
| Where you’re posting | Per-file limit | Notes |
|---|---|---|
| Discord, free account | 10 MB | Lowered from 25 MB in Sept 2024 |
| Discord, Nitro Basic ($2.99/mo) | 50 MB | Official Nitro comparison |
| Discord, Nitro ($9.99/mo) | 500 MB | |
| Discord, Level 2 / Level 3 boosted server | 50 MB / 100 MB | Applies to all members, per the Server Boosting FAQ |
| Slack, every plan | 1 GB | Add files to Slack |
| Slack, free workspace storage | 5 GB total | Files hidden after 90 days (usage limits) |
A few Discord-specific footnotes:
- GIFs from the Tenor picker don’t count. Those are embedded links, not uploads, so the 10 MB cap only applies to files you attach yourself.
- Emoji and stickers are separate. Animated server emoji are capped at 256 KB and stickers at 512 KB regardless of Nitro status. This guide is about chat uploads.
- The boost-level and Nitro limits don’t stack; you get whichever is highest.
Slack’s 1 GB per-file limit means you’ll never get a “file too large” error for a GIF. But on a free workspace, a handful of 50 MB GIFs eats a real chunk of your 5 GB shared storage, and they vanish from view after 90 days anyway. Keep them small.
How each app treats your GIF after posting
Both apps autoplay GIFs by default, which is exactly why file size matters more than the upload cap alone.
- Discord autoplays uploaded GIFs while the window is focused. Users can turn this off under Settings → Accessibility, but most never do.
- Slack autoplays animations by default on desktop and mobile; the off switch is in Preferences → Accessibility (Slack’s docs). When disabled, GIFs show as stills until clicked.
So your GIF plays automatically for nearly everyone who scrolls past it, including people on phones with metered data. A 40 MB GIF in a busy channel isn’t blocked by Slack, but it’s still rude.
Why GIFs get huge
GIF is a 1989 format. Every frame is stored as a full indexed-color image (or a diff rectangle), compressed with LZW, with at most 256 colors per palette. There is no motion compensation, no inter-frame prediction, none of the tricks that make H.264 video small. A clip that’s 1 MB as MP4 can easily be 15 MB as GIF.
That leaves you exactly four levers, and they multiply together:
file size ≈ duration × pixels per frame × framerate × color complexity
Halve any one of them and you roughly halve the file. The workflow below pulls all four.
The workflow: under 10 MB in five steps
Baseline example: a 10-second 1080p screen recording at 30 fps. Converted naively (full resolution, full framerate, 256 colors), that’s typically 30–60 MB as a GIF. Here’s how to get it under 10.
1. Trim first (linear savings)
Every second you cut is a proportional cut in file size. Most “look at this bug” or “here’s the new feature” clips only need 4–6 seconds. Trim dead time at the start, the fumbling at the end, and any pause in the middle. This is the cheapest win and the one people skip.
2. Resize to 480 px wide (the big one)
Pixel count scales with the square of the dimensions. Going from 1920 px wide to 480 px is 1/16 the pixels per frame. Chat columns render media small anyway; nobody is inspecting 1080p detail inline in Discord. 480 px keeps UI text readable for most interfaces; drop to 360 px only if you’re desperate.
If the GIF already exists, run it through a GIF resizer. If you’re converting from video, set the width during conversion so you never decode pixels you’ll throw away.
3. Drop to 15 fps
Screen recordings are usually 30 or 60 fps. 15 fps halves (or quarters) the frame count and still looks smooth for cursor movement and UI transitions. Terminal demos and slideshows look fine at 10–12 fps. Only fast motion, like gameplay, visibly suffers below 20.
4. Cut colors to 128
Going from 256 to 128 colors typically shaves 10–25% (LZW compresses smaller palettes better, but it’s not linear). Screen recordings of flat UIs, especially dark themes, often look identical at 128 or even 64 colors. Photographic or gradient-heavy content will band; for those, stay at 256 and lean on the other levers.
5. Lossy-compress the result
Modern GIF optimizers (gifsicle’s --lossy flag and tools built on the same idea) introduce small artifacts that LZW can compress much harder. A lossy level of 60–80 is usually invisible on screen content and cuts another 30–50%. Run your finished GIF through a GIF compressor as the final pass, after trimming and resizing, not before.
Settings → expected size cheat sheet
Ballpark output sizes for a 10-second screen recording (1080p source, moderate motion: typing, scrolling, clicking around a UI):
| Width | FPS | Colors | Lossy | Expected size |
|---|---|---|---|---|
| 720 px | 20 | 256 | off | 12–20 MB ❌ |
| 480 px | 15 | 256 | off | 4–8 MB ✅ |
| 480 px | 15 | 128 | ~80 | 2.5–5 MB ✅ |
| 360 px | 12 | 128 | ~80 | 1.5–3 MB ✅ |
| 320 px | 10 | 64 | ~120 | under 1.5 MB ✅ |
Big caveat: motion dominates. A mostly-static terminal demo lands at the low end of each range. Scrolling a long page or panning video content can double these numbers, because almost every pixel changes every frame and GIF has no answer for that except brute force.
So the practical recipe is: trim to ≤ 10 s, 480 px, 15 fps, 128 colors, lossy ~80. That lands a typical screen capture at 2–5 MB, comfortably under Discord’s cap with room for a longer clip when you need it.
Still over 10 MB?
In order of what hurts least:
- Cut the clip to 5–6 seconds. Loop it; viewers will catch it on the second pass.
- Go to 360 px. Acceptable for “watch the motion” clips, bad for reading text.
- Crank lossy to 100–120. Visible grain on gradients, fine on flat UI.
- Stop using GIF. Convert GIF to MP4 instead. The MP4 is typically 5–10× smaller with better color. The tradeoff: Discord and Slack show video with a play button rather than autoplaying it inline. If autoplay is the point, GIF earns its bloat; if quality and size matter more, MP4 wins every time.
- Nitro Basic at $2.99/month raises your cap to 50 MB if you hit this wall weekly. Cheaper than your time.
One note on privacy
Screen recordings are the riskiest files people casually share: they catch API tokens, customer emails, internal URLs, and Slack messages in other windows. If you use a web-based converter, prefer one that processes files locally instead of uploading them to a server. GIF Den’s video to GIF converter does all of this in-browser via WebCodecs, and you can confirm nothing leaves your machine in about two minutes with the network tab open: how to verify no-upload claims. Whatever tool you use, that check is worth doing once.
Checklist
- Trim to 10 seconds or less (5–6 is usually plenty)
- Resize to 480 px wide (360 px as fallback)
- Set framerate to 15 fps (10–12 for terminal/UI demos)
- Reduce to 128 colors (64 for flat dark-mode UIs)
- Lossy-compress at ~80 as the final pass
- Verify the file is under 10 MB before posting to Discord
- If it won’t fit, ship an MP4 and accept the play button