Why Are GIFs So Big?

GIF was published in 1987, by CompuServe, for dial-up. It predates the World Wide Web by two years and every modern video codec by more than a decade. It is remarkable that it still works everywhere. It is not remarkable that it is inefficient.

Understanding why it is inefficient is genuinely useful, because it tells you which knob to turn when a GIF is too big — and when to stop turning knobs.

Three design decisions account for almost all of the size:

1. A palette of at most 256 colors. Each frame carries a color table with up to 256 entries, and every pixel is an index into it. A photograph has far more than 256 distinct colors, so it has to be quantized, and the quantization is usually hidden with dithering — which, as we will see, costs bytes.
2. LZW compression, within a frame only. LZW finds repeated byte runs. It is decent on flat, blocky content and poor on noisy, detailed content. Crucially it operates on one frame’s pixel indices at a time. It has no concept of the previous frame.
3. No motion compensation. This is the big one. Modern codecs encode a frame as “the last frame, but this block moved eleven pixels left.” GIF has nothing like it. The best it can do is a frame-differencing trick where a frame only redraws a changed rectangle, which helps on screen recordings with a still background and helps almost not at all on anything with camera movement.

Put those together and the size of a GIF is roughly: frames × pixels × how compressible each frame’s indexed data happens to be. No setting changes that structure. Every optimization is a way of reducing one of those three terms.

Take a screen recording of someone typing into a form. In H.264, the first frame is stored in full and every frame after it is stored as a small set of differences: the cursor moved, six characters appeared. The unchanged nine tenths of the screen costs almost nothing.

In GIF, that unchanged nine tenths is paid for again on every frame that has to be redrawn, and it is paid for in palettized pixels with a compressor that cannot see across frames. Add the fact that H.264 uses a full color space, spends bits where motion actually is, and applies perceptual quantization, and the outcome is not close.

This is why every platform that once encouraged GIFs quietly converts them to video behind the scenes. When you post a “GIF” on X, Reddit, or Discord, what actually plays back to other people is usually an MP4. The format survived as a user-facing idea — short, silent, looping, autoplaying — long after it stopped being the format doing the work.

Since size is frames × pixels × compressibility, there are exactly three places to attack, and they have very different exchange rates:

The counterintuitive row is the last one. Dithering is the standard fix for a reduced palette, but it works by adding high-frequency noise, and LZW compresses noise badly. On flat content, turning dithering down both looks better and produces a smaller file.

There is a floor. If your GIF is already under 12 frames per second, under 400 pixels wide, and down to 64 colors and it is still too large, you have exhausted the format. No compressor is holding out on you.

At that point the answer is convert it to MP4. Discord, Slack, X, and every browser autoplay short muted MP4s inline and loop them, which is what people wanted from a GIF in the first place. The two remaining GIF-only cases are email newsletters, where clients will not play video, and upload fields that accept images only.