How to Reduce GIF File Size: What Actually Works (Tested)

The fastest way to reduce a GIF's file size is to make it smaller on screen: halving the width and height cut our test GIFs by 51–67% on its own. After that, let unchanged pixels be skipped between frames (lossy or "optimize transparency" settings), then drop every second frame. Cutting the colour count — the setting most guides lead with — was the weakest lever in our tests and made one GIF larger.

Those conclusions come from compressing four real screen-recording GIFs with each setting separately and together. The numbers are below, followed by five ways to apply them: in the browser, on the command line, with an online tool, by re-exporting from the source video, or by not using a GIF at all.

Quick comparison

Why GIFs get so big

GIF is a 1987 format that stores animation as a sequence of pictures, each limited to 256 colours and compressed with LZW, a lossless method. Two things follow:

• Every pixel of every frame costs something. A 1280 × 800 GIF at 15 fps pushes about 15 million pixels per second through the encoder. There is no motion prediction of the kind MP4 uses.
• Noise is expensive. LZW compresses flat areas of colour well and gradients, shadows, photos and dithering badly. Dark UI backgrounds with soft gradients — common in screen recordings — are close to the worst case.

Two popular explanations are wrong, and they lead people to the wrong settings. GIFs do not need a separate colour table for every frame (a single shared table is normal), and they can store only what changed between frames: a frame may mark pixels as transparent, meaning "keep what the last frame showed". Many encoders simply don't use that, which is why the same animation can differ in size by several times depending on how it was made.

What we tested

We made three GIFs from our own raw screen captures with ffmpeg at 15 fps — a 5-second and a 15-second desktop clip at 1280 px wide, and a 28-second iPhone clip at 480 px — and added one real-world screen-recording GIF that had already been through a good encoder. Each was compressed with one setting at a time, then with combinations, using our GIF Compressor. Percentages are savings against the original file.

What the table says:

1. Scale is the most reliable lever. It was the only setting that worked well on all four files. Halving each dimension leaves a quarter of the pixels, and file size follows.
2. Skipping unchanged pixels depends on the content. The 5-second clip is mostly a still headline with a moving cursor, so Medium alone removed 71%. The clips that scroll and animate gained far less.
3. Dropping frames is steady but moderate — roughly a third to a half — and costs smoothness, not sharpness.
4. Re-encoding a well-made GIF without changing anything can make it bigger. The real-world GIF grew 22%. If a tool shows you a larger file, it isn't broken; that file was already tight, and only real reductions (smaller size, fewer frames) will help.
5. Combining settings compounds. The last row takes every GIF under 5 MB — the 5-second clip from 4.2 MB to 190 KB.

Colour reduction deserves its own note: going from 256 to 128 colours saved 6–10% on three GIFs and made the fourth 15% larger, while visibly banding gradients. Try it last.

Method 1: Screenify's free GIF Compressor (in the browser)

Our GIF Compressor runs entirely in your browser — the GIF is decoded and re-encoded on your device and never uploaded — and it shows the original and compressed GIF side by side with the new size.

1. Open the GIF Compressor and drop in a GIF (up to 50 MB).
2. It compresses immediately with full size, all frames and Medium compression, and shows the result.
3. If the file is still too big, lower Scale first, then set Frames kept to Half, then try Strong compression. Each change re-runs automatically.
4. Compare the previews — zoom in on small text — and click Download GIF.

Why it is Method 1 here: it applies the two levers that worked best in our tests (scale and skipping unchanged pixels) with a live size readout, so you can stop as soon as you hit your target. It also warns you when a setting makes the file larger, which the real-world GIF above would have triggered.

Method 2: gifsicle (free, command line)

gifsicle is the long-standing open-source GIF optimiser. On a Mac, install it with Homebrew:

brew install gifsicle

Then combine the options that matched our best results:

gifsicle -O3 --lossy=80 --resize-width 640 input.gif -o smaller.gif

• -O3 tries several optimisation methods, including storing only the changed part of each frame.
• --lossy=80 allows artifacts in exchange for smaller output; higher values shrink more and look worse (the default is 20).
• --resize-width 640 scales the GIF, keeping its aspect ratio. Use --scale 0.5 to halve it instead.
• --colors 128 reduces the palette — add it last, if at all.

To keep every second frame, select frames with gifsicle's #0-10 range syntax, or — usually simpler — re-export from the original video with a lower frame rate (Method 4). Run gifsicle --help for the full list.

Pros: scriptable, fast, handles folders with a shell loop. Cons: no preview; you check each result by opening it.

Method 3: ezgif.com (online)

ezgif's Optimize page offers lossy compression, colour reduction and frame dropping, and the site bundles resize, crop and speed tools alongside.

1. Upload the GIF on ezgif's optimizer page.
2. Choose a method — "Lossy GIF" with a compression level is the closest to the settings that worked best above.
3. Download the result, or chain it into the Resize tool for further savings.

Pros: no install, many editing tools in one place. Cons: your file is uploaded to a third-party server, which may matter for screenshots of internal apps or customer data.

Method 4: Re-export from the original video

If the GIF came from a screen recording and you still have the video, re-exporting beats compressing. Compression can only remove detail from a GIF; a fresh export can choose a sensible width and frame rate from the start, so the extra pixels and frames never exist.

• Screenify Studio exports GIF directly from the editor timeline, with the frame rate (5 to 60 fps; 15 is the recommended balance) and output size set before export. Free plan for macOS.
• Gifski (free, Mac App Store) produces high-quality GIFs from a video with width, frame rate and quality sliders.
• ffmpeg can do it in one command with a generated palette — this is exactly how we made the test GIFs above:

ffmpeg -i recording.mov -t 10 -vf "fps=12,scale=640:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" out.gif

• In the browser, our Video to GIF tool takes an MP4 or MOV, lets you pick width, frame rate and clip, and never uploads the video. On a 10-second desktop recording it produced a 1.12 MB GIF at 640 px and 12 fps.

A useful fact from that last test: going from 10 to 20 fps grew the GIF by only 45%, not 100%, because consecutive frames of a screen recording are nearly identical. Width matters more than frame rate.

Method 5: Don't use a GIF

If the place you're posting plays video, an MP4 of the same clip is dramatically smaller and looks better, because it isn't limited to 256 colours. Our GIF to MP4 converter turned the same four test GIFs into MP4s 2.3 to 11.2 times smaller. GitHub, for instance, accepts MP4, MOV and WebM uploads in issues and pull requests, and on a web page a <video autoplay loop muted playsinline> tag behaves just like a GIF.

Keep the GIF where only images work: README images embedded with Markdown, most documentation tools, and email.

A worked example: getting under GitHub's 10 MB

Say you have the 15-second desktop recording from our tests — an 18.9 MB GIF, 1280 px wide — and want to attach it to a GitHub issue, which caps images and GIFs at 10 MB.

1. Try the default first. Medium compression alone brought it to 12.1 MB (−36%). Close, but still over the limit: this clip scrolls, so too many pixels change between frames for skipping to do most of the work.
2. Add scale. At 75% scale plus Medium, it came out at 6.8 MB (−64%) — comfortably under 10 MB. Check small UI text in the preview before accepting; 75% of a 1280 px recording is 960 px wide.
3. Stop there. There's no prize for going smaller than the limit if it costs legibility. If you needed it under 2 MB — for an email, say — 50% scale with 128 colours and Strong compression reached 1.5 MB, at the price of noticeably softer text.

The iPhone clip needed a different route. At 480 px wide it was already narrow, so scaling hurt more: 50% scale alone left it at 11.2 MB, still over. On their own, keeping every second frame saved 46% and 50% scale saved 66% on this clip, so combining the two is the next thing to try for a long, narrow recording — or, since it is 28 seconds long, converting it to MP4, which took it from 33 MB to between 3 and 6 MB depending on the browser.

The pattern generalises: short, mostly-still clips shrink most from skipping unchanged pixels; long or busy clips need scale or fewer frames. Look at your GIF before choosing — if most of the screen moves (scrolling, video playback, animated backgrounds), go straight to scale.

How "skip unchanged pixels" works

Every GIF frame can declare some of its pixels transparent. With the right disposal setting, a transparent pixel means "leave whatever the previous frame showed here". An optimiser compares each frame with the one before, and wherever nothing changed it writes a transparent pixel instead of the colour. Long runs of the same transparent value compress with LZW to almost nothing, so a frame where only a cursor moved costs a few hundred bytes instead of the whole screen.

"Lossy" settings extend the idea: pixels that changed only slightly — a gradient that shifted by one shade, video compression noise in the source — are also treated as unchanged. That is where the big savings on the 5-second clip came from, and also where artifacts appear if you push it too far: a slowly fading gradient can freeze in patches instead of fading smoothly. If you see blotches, step back one level.

How small does it need to be?

Limits change, so check the platform you're posting to. One we verified: GitHub allows images and GIFs up to 10 MB when you attach them to issues, pull requests and comments. For chat apps, a GIF of a few megabytes loads quickly on any connection, while one of 20 MB or more makes people wait — even when it is technically allowed.

If you have a hard limit, work backwards from the table: scale alone roughly halves or thirds the size, and scale plus lossy compression gets most screen-recording GIFs down by 50–85%.

Troubleshooting

My GIF got bigger after compressing

It was already well optimised, and re-encoding without shrinking anything added overhead — our real-world test GIF grew 22%. Reduce the scale or the number of frames; those always shrink the file.

Text became blurry

That's scale. Screen recordings of UI text show it first. Go back up one step (for example, 75% instead of 50%) and make up the difference with frame dropping or lossy compression instead.

Dark backgrounds turned blotchy or banded

That's colour reduction or heavy lossy compression acting on gradients. Keep 256 colours, use a lighter lossy setting, and if the source video is available, re-export with dithering (ffmpeg's paletteuse dithers by default).

The animation looks choppy

Frames were dropped. For fast cursor movement or scrolling, keep all frames and reduce size instead. Timing shouldn't change: a well-behaved compressor adds the dropped frames' display time to the frames it keeps, so the GIF lasts just as long.

The GIF plays too fast after compression

Some tools discard frame delays when dropping frames. Re-run with a tool that preserves timing — our compressor and gifsicle both do — or check the frame delay in the output.

FAQ

What is the best way to compress a GIF without losing quality?

Run gifsicle with -O3 and no --lossy or --colors option. It rewrites each frame to store only what changed, which removes redundant data without touching a single visible pixel — but on a GIF that was already well made, the saving may be small. Browser tools that re-encode (ours included) re-pick the palette for each frame, so even their gentlest setting is near-lossless rather than bit-identical. Everything else — scale, frames, colours, lossy — trades some quality for size.

How do I reduce a GIF to under 5 MB?

Start with 50% scale; in our tests that alone cut 51–67%. If you're still over, keep every second frame, then use a stronger lossy setting. Every GIF we tested got under 5 MB with 50% scale, 128 colours and strong lossy compression.

Does reducing colours make a GIF smaller?

A little, sometimes. In our tests, 128 colours instead of 256 saved 6–10% on three GIFs and made the fourth 15% larger, while banding gradients. It's the lever to try last.

Is it safe to use online GIF compressors?

Most upload your file to their server. That's fine for memes; think twice for screenshots of internal tools, dashboards or customer data. Browser-based tools that process locally, and command-line tools like gifsicle, keep the file on your machine.

Why is my screen-recording GIF so large?

Because GIF stores many full-size frames with only 256 colours each and no motion prediction, and screen recordings are often recorded at full Retina resolution. Recording or exporting at the width you'll actually display (often 640–800 px) prevents most of the size.

Should I use WebP or MP4 instead of GIF?

If the platform supports it, yes — both compress animation far better. MP4 is the most widely accepted; animated WebP works in modern browsers but not everywhere a GIF does.

Related

• How to Convert Video to GIF on Mac — four ways to make a GIF from a recording in the first place
• How to Reduce Video File Size on Mac — the same problem for MP4 and MOV recordings
• Free GIF Compressor · Video to GIF · GIF to MP4