Does a GIF Compressor Preserve Loop Count?

Measured production output

Two different loop sources produced the same output loop value

Method: scripts/verify-gif-compressor-loop-count.mjs generated two 16 × 16, two-frame fixtures, processed them through the production compressor in headless Chrome, then inspected the exact output bytes and decoded frames. The finite source was 145 bytes; the no-extension source was 126. Light was 145, Balanced 131, Smallest 75, and no-extension-to-Light 145 bytes. These values describe these fixtures only.

Encoder boundary

The compressor does not read and carry the source loop value

The current compressor decodes image frames, composites them, applies the selected preset, and passes repeat: 0 when it writes the first output frame. It does not extract a source repeat value and pass that value to the encoder.

The bundled encoder writes the NETSCAPE2.0 application extension when the repeat option is zero or greater. Its loop field is a two-byte value. The production audit inspected that field directly rather than inferring it from a short screen recording.

Finite source

A finite loop value became the encoder's endless-loop value

The first fixture contained two solid-color frames, each recorded for 100 ms, plus a NETSCAPE2.0 loop value of 3. Light and Balanced retained both frames and both 100 ms delays, but their loop value was 0. Smallest retained one image with a 200 ms delay and also wrote 0.

This separates two independent results. Light preserved the fixture's frame count and delays, yet it did not preserve how many times the animation was instructed to repeat. The animation-speed audit covers per-frame timing; this page covers repetition after the last frame.

No loop extension

Compression can add loop metadata that the source did not contain

The second fixture used the same two frames and delays but omitted the NETSCAPE2.0 extension. Its Light output contained the extension with value 0. The output was therefore a rebuilt animation with a new repeat instruction, not a block-for-block preservation of the source.

This result matches the compressor's implementation: the first output frame always receives repeat: 0. It does not depend on the source having a loop extension. The GIF89a specification defines application extensions as a way for applications to add data; this audit records the exact extension written by the bundled encoder.

A repeatable loop check

How to review repetition after compression

1. Keep the original. The compressor does not offer a repeat-count control or preserve the source value.
2. Replay past the first cycle. A correct first pass does not prove that the animation stops or repeats as intended.
3. Check the destination. Test the downloaded file in the page, editor, presentation, or app where it will be used.
4. Use a metadata inspector when repeat count matters. Confirm whether the output contains a loop extension and which value it stores.
5. Keep or repair deliberately. Retain the original when its finite or absent loop instruction matters, or set the required repeat behavior in a tool that exposes that control.

The result panel reports dimensions, frame count, and bytes, but it does not report repeat metadata. A smaller file can still have the wrong loop behavior for a slide, demonstration, or one-time animation.