How to reduce GIF file size without trashing quality
GIFs punch above their weight for sharing product demos and bug reports, but they're huge compared to video. A 5-second 1080p clip that's 2 MB as MP4 can easily be 20 MB as a GIF. This is a quick field guide to the four levers that actually move the needle — and the settings that work for specific targets like Slack, Discord, and GitHub READMEs.
Why GIFs are so big
GIF is a 1987-era format. It stores each frame with lossless compression against a 256-color palette and has no real inter-frame compression — each frame is roughly independent. Video codecs like H.264 and AV1 exploit similarities between frames to squeeze files by 10–50×. GIF does not.
That one fact drives every optimization tip below. Anything that reduces total pixels — shorter duration, fewer frames, smaller dimensions — shrinks the file roughly linearly. Anything that tweaks color quality helps at the margins.
The four levers
1. Trim, then trim again
This is by far the biggest lever. File size scales almost exactly linearly with duration. Before reaching for any other setting, trim down to just the beats you actually need. A 3-second GIF is 5× smaller than a 15-second GIF at the same width and FPS. If the bug/demo has any lead-in time, cut it.
2. Reduce the width
Width drives the pixel count per frame and therefore the file size quadratically (a 720 px GIF has 2.25× the pixels of a 480 px GIF of the same aspect ratio). Most messaging apps display GIFs in a column narrower than 600 px anyway, so you're not losing anything by dropping from 1080 px to 480 px — the reader never sees the original detail.
- 720 px — README hero, high-detail code walkthrough
- 480 px — the "just right" default for Slack, Twitter, blog posts
- 360 px — Discord reaction GIFs, phone-first contexts
- 240 px — tiny reaction GIFs, emoji-adjacent use
3. Lower the FPS
File size scales roughly linearly with frames per second. Dropping from 24 FPS to 15 FPS is ~38% off the file, and most UI content looks identical. Going to 10 FPS is another ~33% saving on top of that. You only really need 24+ FPS for high-motion video (action, sports).
We wrote a companion piece on this: Picking the right FPS for a GIF.
4. Use a custom palette (2-pass)
The default GIF palette is a generic 256-color table. A two-pass encode first analyzes your clip to build a palette tuned to your colors, then applies it. For the same file size you get less banding in gradients and cleaner brand colors. It takes longer, but the output looks noticeably better for UI recordings, screenshots of design tools, and anything with subtle gradients.
In localgif.app this is the "Better (2-pass)" quality option; "Smaller (1-pass)" is the default-palette fallback.
Quick settings for common targets
| Target | Width | FPS | Aim under |
|---|---|---|---|
| Slack message | 480 px | 15 | 5 MB |
| Discord (free tier) | 360–480 px | 10–12 | 10 MB |
| GitHub README hero | 720 px | 15 | 5 MB |
| Email (Gmail inline) | 480 px | 12–15 | 2 MB |
| Twitter/X post | 480 px | 15 | 15 MB |
When not to shrink
If your GIF shows code, dense UI, or small interactive controls, width matters more than file size. A 240 px GIF of a code walkthrough is useless even if it's 200 KB. Start at the width you need for legibility, then cut duration and FPS until the file is acceptable. Don't sacrifice readability to chase a smaller byte count.
Alternatives: when GIF is the wrong format
If the destination supports video, video will always be dramatically smaller than GIF at the same quality:
- Twitter/X accepts video and will often re-encode your GIF as MP4 on upload anyway.
- GitHub Issues and PRs accept MP4 and WebM via drag-and-drop (up to 10 MB).
- Slack plays inline MP4 on most plans.
- Discord plays MP4 and WebM inline with full audio.
If you need autoplay in a Markdown README or in an environment that doesn't support inline video, GIF is still the right tool — and the tips above still apply.
Try it
All of this runs in your browser at localgif.app — drop a video in, trim it, tune FPS and width, and watch the file size shrink in real time. Nothing is uploaded, so it works for internal screen recordings and early demos too.