Reduce GIF File Size Without Wrecking the Picture

GIF compresses with LZW, scanning each row for repeated byte sequences and replacing them with shorter codes. It works brilliantly on flat colour and poorly on noise, and — this is the important part — it has no concept of motion. Every frame is compressed on its own terms.

Modern video codecs do the opposite: they store one full frame and then describe how the following frames differ from it. That is why a video of a mostly static screen recording is tiny and the same recording as a GIF is not. GIF does support skipping unchanged regions between frames, but it is a much weaker mechanism than motion compensation, and any noise, dithering or camera movement defeats it.

File size scales with pixel count, which scales with the square of the linear dimension. Going from 640 px wide to 480 px removes about 44% of the pixels before any encoder setting is touched. Going to 320 px removes 75%.

This is almost always the first thing to try, because a GIF is nearly always displayed smaller than it was authored — inside a chat window, a documentation page, a ticket. Exporting at the size it will actually be shown costs nothing visually and is the cheapest large win available.

Bytes scale almost linearly with frames, so halving the frame rate roughly halves the file. Trimming dead time at the start and end is even better, because those frames contribute nothing at all.

Watch your clip and count how many frames are actually load-bearing. A demo that takes eight seconds usually has two seconds of someone finding the cursor at the start and a second of nothing at the end. Cutting those is free.

Less linear than people expect. Dropping 256 to 128 colours is often visually free and saves 20–30%. Dropping 32 to 16 usually looks obviously worse for a much smaller absolute gain, because by then the palette is no longer the dominant cost.

Material matters more than the number. Anything with large flat areas tolerates aggressive reduction; anything with gradients — skies, skin, shadows, soft shadows behind text — falls apart quickly and needs dithering to stay acceptable.

Dithering approximates missing colours by mixing available ones into a fine pattern. It removes banding, and it makes flat regions noisy — which is exactly what LZW compresses worst. On the wrong material it grows the file while making it look busier.

Ordered (Bayer) dithering uses a fixed pattern, so it repeats and compresses better than the error-diffused alternative. Floyd–Steinberg looks smoother on photographs but produces non-repeating noise. On flat graphics, no dithering at all is both smaller and cleaner.

Given a 4 MB GIF that needs to be under 1 MB, work down the list rather than reaching for a single "compress" slider.

If you have trimmed, halved and shrunk and it is still too big, the material is telling you something. Long clips, camera movement and photographic gradients are all things GIF is structurally bad at.

MP4 and WebM handle exactly those cases an order of magnitude better, and almost every destination now accepts them. Reach for GIF when inline autoplay with no player is a hard requirement, and for video when it is not.