GIF Re-Encoding Can Boost File Size by 450%

Testing a new GIF encoder revealed a scenario that seemed physically impossible. A 288-frame animation of a Foucault pendulum—a relatively simple loop—was re-encoded. Instead of the file size staying roughly the same or shrinking, it exploded from 1,074 KB to 4,881 KB. That is a 455% increase. A similar disaster occurred with a gun turret animation that grew from 116 KB to over 1.2 MB.

When a re-encode inflates files so drastically, it indicates the encoder fails to compress and instead discards the optimization intelligence present in the source.

Why your encoder is killing your file size

Understanding this requires looking at how an optimized GIF functions. A GIF is not merely a stack of full images. A smart encoder writes the first frame as a complete image, but for every subsequent frame, it records only the pixels that actually changed. It sets the "disposal method" to "do not dispose," instructing the decoder to keep the previous frame on the canvas and simply paint the new, tiny layer of changed pixels on top.

In the pendulum example, the background is a static, dark rig. Only a few percent of the pixels (the swinging bob) are moving. The original source was incredibly efficient because it only "paid" for the bob in every frame.

The encoder, however, was being too "correct." It wrote every single frame as a full-canvas, fully opaque keyframe. Although the animation looked perfect, it forced the user to re-download the static background hundreds of times.

Implementing interframe differencing

To fix this, a delta-based approach is implemented. For opaque sources, frames are written as the previous frame plus only the changed pixels. A transparent palette index is used for the unchanged areas and the disposal is set to "do not dispose."

Here is the logic used to identify the delta mask:

function changedPixels(cur, prev) {
 const count = cur.length / 4;
 const mask = new Uint8Array(count);
 let changed = 0;
 for (let p = 0, i = 0; p < count; i += 4, p++) {
 if (cur[i] !== prev[i] || cur[i + 1] !== prev[i + 1] || cur[i + 2] !== prev[i + 2]) {
 mask[p] = 1;
 changed++;
 }
 }
 return { mask, changed };
}

Note that this specific implementation is for RGB-only sources where alpha is already 255. If the source has actual transparency, the full keyframe path must be used because the transparent index is already "spoken for" in the palette.

Because gifenc hard-codes the image descriptor to x=0, y=0, sub-rectangles at specific offsets cannot be written like some other encoders. The optimization relies entirely on LZW compression. LZW excels at collapsing long runs of identical values. By filling the "unchanged" areas with a single transparent index, massive runs are created that LZW can squash into almost nothing.

The failure of pixel-count heuristics

A simple threshold was initially tried to decide between delta and keyframe: "If more than X% of pixels changed, just write a full keyframe."

It failed miserably. Testing showed:

• 13% pixel change: Resulted in 74% of the size (Delta won)
• 26% pixel change: Resulted in 112% of the size (Keyframe won)

The math is backwards. The file that changed twice as much was actually smaller when using deltas, while the one that changed less was heavier. This happens because LZW does not care about the count of pixels; it cares about how scattered they are. A few pixels scattered randomly across the screen are much more expensive to encode than a large, solid block of changed pixels.

Instead of guessing with a threshold, the encoder now takes three sample frames, encodes them both ways (delta vs. keyframe), and picks the winner.

A technical trap for the implementation

Watch out for memory management when packing these changed pixels. When preparing the buffer for quantization, a fresh allocation is required. Never use a subarray view.

const out = new Uint8ClampedArray(changed * 4);

Passing a view into functions like quantize() or applyPalette() risks silent corruption or massive overhead if the underlying logic expects a specific buffer length or behavior that a view will not provide.