Why a 5-Second GIF Can Be Bigger Than a 30-Second MP4

A 5-second GIF, heavier than a 30-second video

It sounds backwards the first time it happens: a 5-second GIF export comes out at 8MB, while the 30-second MP4 it was cut from is 6MB. Same footage, same camera, same phone — the shorter clip is the bigger file. It's not a bug in whatever converter made it, and it's not a sign something went wrong. GIF and MP4 are not the same kind of file wearing different extensions; they're two different strategies for storing a moving picture, and one of those strategies is simply much less efficient than the other.

Understanding why comes down to three things: how GIF stores color, what happens when you ask it to fake more color than it has, and how it compresses motion — or rather, how it mostly doesn't.

GIF is an image format doing a video's job

An MP4 stores each frame as full color — millions of possible shades, the same range a photo can hold. A GIF can't do that. The format caps every frame at a palette of at most 256 colors, and every pixel in the frame is stored as an index into that palette rather than as color values directly. That limit isn't a setting some encoders respect and others ignore — it's baked into the GIF spec itself, from 1987, and nothing gets around it.

256 colors sounds like plenty until you point it at real footage. A phone photo of a sunset, a gradient in a UI, skin tones under mixed lighting — all of these routinely contain many thousands of distinct colors in a single frame. Converting that frame to GIF means picking the 256 (or fewer) colors that represent it best and mapping everything else to the nearest one. That step is called quantization, and it's not optional — every MP4-to-GIF or MOV-to-GIF conversion does it, regardless of which tool performs it. The only real choices are how many colors to keep and how to handle the color information that gets thrown away.

One palette, built once, reused for every frame

There are two ways to handle the palette across a multi-frame GIF: rebuild it fresh for every single frame, or build one shared palette and reuse it throughout. A fresh palette per frame is more accurate — each frame gets the best possible 256 colors for exactly what's in it — but it's slower to encode and, more importantly, forces a fresh 256-entry color table to be stored again and again. A shared palette costs that overhead once, and it's the more common approach for exactly that reason.

To build a good shared palette without decoding every pixel of every frame, a practical shortcut is to sample a bounded number of pixels spread across all the frames the clip will actually use — enough to represent the range of color in the clip without scanning the whole thing — and quantize a palette from that sample. Past a certain sample size, feeding in more pixels stops meaningfully improving the result; it just makes longer clips slower to convert.

The trade-off shows up when a color appears briefly in one frame but isn't well represented in the overall sample — a flash of a saturated color for half a second in an otherwise muted clip, say. Because the palette was built from the clip as a whole, that frame's distinctive color gets snapped to whatever's nearest in the shared table, even if a frame-specific palette would have kept it accurate. This is a genuine accuracy-for-efficiency trade, not a bug, and it's part of why a screen recording with mostly flat colors converts to GIF far more faithfully than a clip with a lot of fast color variation.

What dithering actually trades away

Snapping every pixel to the nearest of 256 colors has a visible side effect: smooth gradients — a sky, a shadow, a soft light falloff — stop being smooth. Instead of a gradual shift, you get visible bands, because a range of similar source colors all got mapped to the same one or two palette entries. This is the single most recognizable "GIF" artifact.

Dithering is the standard fix, and Floyd-Steinberg error diffusion is the classic version of it. The idea: when a pixel gets rounded to the nearest palette color, that rounding has an "error" — the difference between what the pixel actually was and the color it got assigned. Instead of discarding that error, it gets spread into the neighboring pixels that haven't been processed yet, nudging their own rounding slightly to compensate. Do this across a whole gradient and the hard bands disappear, replaced by a fine, grainy pattern that reads as smooth at normal viewing size — your eye blends the noise back into something closer to the original gradient.

The catch is what that grain does to compression. GIF's actual data compression — separate from the palette — is LZW, a general-purpose scheme that shrinks a file by finding repeated patterns and storing them once. Flat, undithered regions with long runs of the exact same color index compress extremely well under LZW. The fine noise pattern dithering introduces is, by design, not repetitive — it's specifically there to break up flat color the eye would otherwise see as banding. That makes it meaningfully harder for LZW to compress. Dithering doesn't just fail to help file size; it actively works against it, often adding somewhere in the ballpark of 10–20% to the output for a real improvement in how gradients look. It's a legitimate trade — better for photographic content, skin tones, skies — and one worth turning off for flat-color material like UI recordings or line art, where there's no banding to fix and the noise is pure cost.

The real reason motion kills GIF file size

This is the biggest gap between GIF and video, and the one that explains the "5 seconds bigger than 30 seconds" scenario most directly. Real video codecs almost never store every frame as a complete, independent image. Most frames instead store only what changed since a nearby reference frame — motion vectors and a residual, not a redraw of the whole picture. A static shot of someone talking, where only the mouth and eyes move against an otherwise still background, costs the codec very little per frame after the first one, because most of the frame simply doesn't need to be re-sent. Our breakdown of I-frames, P-frames and how video files are actually structured goes into this in more depth.

GIF has no equivalent mechanism. Each frame's pixel data is compressed on its own terms by LZW, looking for repetition inside that single frame — it isn't comparing frame 12 to frame 11 and encoding only the difference. So a clip with a lot of motion, fine texture, camera shake, or film grain doesn't get the "mostly unchanged, cheap to encode" discount that a real codec gives it. Every frame is close to full price. A busy, high-motion 5-second GIF can end up larger than a 30-second MP4 of much calmer footage simply because the MP4's codec is exploiting redundancy across time that GIF structurally can't.

Frame rate compounds this directly, because every additional frame is another frame paying that full price. This is also why GIF tolerates a much lower frame rate than video without looking obviously wrong: a GIF reads to the eye as a short, repeating loop rather than continuous motion, so 8–10 frames per second is often enough to look natural, where a video needs something closer to 24–30fps to avoid looking choppy. Above roughly 20fps, GIF stops gaining much — the eye isn't picking up the extra smoothness, but the file is still paying for every one of those frames in full.

Turning the actual knobs

None of this is purely academic — it maps directly onto the settings you actually get when converting a clip to GIF: frame rate, output width, color count, and whether dithering is on. In rough order of how much they save without costing much visible quality:

• Frame rate first. Since GIF has no motion compensation, every frame is expensive, and 8fps reads as smooth for a looping clip in a way it never would for a video. Dropping from 24fps to 10fps or lower is usually the single biggest size reduction available, and for most loop-and-repeat use cases (reactions, short demos, UI walkthroughs) it's close to free visually.
• Dithering, based on content. Leave it on for anything photographic — real footage with gradients, skin tones, natural light. Turn it off for flat-color material — screen recordings, UI demos, text-heavy clips, line art — where there's no banding to fix and the noise it adds is pure file-size cost with no visible benefit.
• Color count next. 256 colors is the right call for photographic content. Screen recordings, memes, and anything with large flat regions often hold up fine at 128 or even 64 colors, since there wasn't that much color variation to preserve in the first place.
• Resolution last. Downscaling always shrinks the file, but it's the most visually obvious cut of the four, so it's worth trying after the others rather than reaching for it first.

If you're starting from a phone or screen-recorded MP4, SquishyFile's MP4 to GIF converter exposes all four of these — frame rate, resolution, color count and dithering — plus trim, crop and speed, and runs the whole thing locally in the browser. Coming from a Mac screen recording or a MOV export instead, the MOV to GIF converter does the same conversion straight from that container, no re-export needed first.

Frequently asked questions