Why Can a GIF Compressor Make a File Larger?

Two reproducible outcomes

The same compressor can shrink one source and grow another

Method: headless Chrome loaded the production compressor, selected a local fixture, ran each preset, fetched the generated Blob, and counted its bytes. The four-frame source is docs/quality-report/swapmygif-before.gif. The 34-byte boundary fixture is the complete GIF89a byte sequence recorded in the test script. These results describe two files, not expected savings for another GIF.

Byte audit · larger case

A tiny source can have nowhere useful to shrink

The 34-byte test file contains one 1 × 1 image. Its source stream has a GIF89a header, logical screen and color table, one image block, and a trailer. It does not contain a loop application extension or a Graphic Control Extension.

The 64-byte output retains the 1 × 1 dimensions and one written frame. Its byte stream includes a NETSCAPE2.0 loop application extension and a Graphic Control Extension before the rebuilt image. The encoder also writes a new image-data stream. Those structures are valid, but their cost is larger than the entire compact source's remaining opportunity for reduction.

The result panel rounded both files to “1 KB” because its compact display never shows less than 1 KB. The percentage was still calculated from the exact Blob sizes: 34 and 64 bytes. For unusually small files, inspect the downloaded file's exact byte count rather than relying on rounded labels alone.

Implementation boundary

Rebuilding rendered frames can discard earlier optimization

SwapMyGIF decodes the source, composites each frame onto a full source-sized canvas, redraws the selected output size, quantizes a palette, and writes a new GIF frame. That makes the result predictable for this tool's presets, but it does not preserve the source encoder's exact block layout, sub-rectangle choices, palette sharing, or compressed image stream.

A source may already store only the changing rectangle or use an efficient palette and LZW stream. Rebuilding full rendered frames can replace those choices with a different tradeoff. The GIF89a specification defines image descriptors, color tables, control extensions, and compressed image data; it does not require two encoders to produce the same byte count for the same visible pixels.

This tool's Light preset keeps dimensions and every decoded frame, but it still rebuilds palettes and image data. Balanced additionally scales both dimensions to 75%. Smallest scales to 50%, limits the palette further, and writes alternate frames. See the exact preset and delay reference before changing motion.

A repeatable diagnosis

What to do when the output is larger

1. Keep the original. Do not overwrite the only copy before comparing the complete result.
2. Read the exact direction. The result explicitly says “smaller” or “larger.” Rounded KB labels can hide a tiny byte difference.
3. Check what the preset changed. Light still re-encodes; Balanced changes dimensions; Smallest changes dimensions, colors, and frame sampling.
4. Replay the whole loop. A smaller byte count is not useful if text, gradients, transparency, fast motion, or the loop boundary no longer works for the intended use.
5. Stop when the pass does not help. There is no target-byte mode and no guarantee that a more aggressive pass will preserve the details you need.

Do not repeatedly compress the previous output while searching for a smaller file. Start each comparison from the original so dimension, palette, and frame losses do not accumulate.