GIF Compressor

A GIF stores each frame as its own palette-indexed bitmap, with no motion compression of the kind video codecs use. There is no concept of describing how pixels moved between frames, so a two-second clip at 25 frames per second is closer to fifty stacked images than to a video. That is why a short GIF can easily outweigh a high-resolution photograph.

Two limits define the format. Each frame can reference at most 256 colours, and compression is LZW over the palette indices, which rewards flat areas and repeated patterns while punishing noise and gradients. Understanding both explains every compression decision below: reducing the palette makes the index stream cheaper, and reducing dithering keeps that stream repetitive enough for LZW to work with.

The levels move the palette size, the dithering strength, and how much error the encoder may accept when it reuses a palette between frames or treats a barely-changed pixel as unchanged. Light keeps 192 colours and is intended to be hard to distinguish from the original. Balanced uses 64 and is the recommended default. Strong uses 32 and starts to show visible banding in gradients. Maximum drops to 8 colours, which is a deliberate trade for the smallest possible file.

Dithering is reduced as the levels get stronger, which sounds backwards but is not. Dithering hides banding by scattering pixels of nearby colours, and that scattering is noise — exactly what LZW compresses worst. At small palette sizes, heavy dithering can leave a file barely smaller than it started, so it is eased off in step with the colour count.

Palette work has a floor, and once you reach it the only things left are pixels and frames. Scaling is the more effective of the two because it applies to every frame at once: halving both dimensions leaves a quarter of the pixels. Every frame is resampled independently and the animation is rebuilt, so the result plays exactly as before at the new size.

Frame reduction keeps one frame in every two or three. The delays of the removed frames are added to the frame that replaces them, so total playback time is unchanged and the animation never runs fast. The cost is smoothness, which matters for fluid motion but is often unnoticeable on screen recordings and text animations that hold still between changes.

Every operation here reads the whole animation rather than the first frame, which is the usual reason a GIF comes back as a still image from online tools. Frame delays are read per frame and written back, and the loop flag that makes a GIF repeat forever is preserved, so nothing stops after one pass.

The frame count of the file you are about to download is measured from the encoded output and shown in the result panel, next to the original count. If those two numbers match, no frames were lost.

Animated GIFs are compressed on our server, because browsers can decode animation but cannot re-encode it. Your file travels over HTTPS, is held in memory for the few seconds the work takes, and is discarded when the response is sent. It is never written to disk, logged, indexed or shared, and nothing is retained after your download.