Why Your GIF Stops Looping After Resizing

GIF looping isn't stored in the pixel frames — it lives in a small piece of metadata called the NETSCAPE2.0 application extension, which just tells a browser or viewer "loop forever" or "loop N times." When a tool decodes a GIF, resizes or re-encodes it, and writes out a new file, every frame gets rebuilt, but that specific extension block does not carry over automatically the way pixel data does. Many resize and conversion tools rebuild the frames, delays, and color palette correctly but skip rewriting the loop extension, so the exported GIF defaults to playing once. Nothing about the animation itself is broken — every frame is intact — the file has simply lost the one instruction that tells it to keep repeating.

The NETSCAPE2.0 extension is a leftover piece of the original 1995 GIF89a spec: Netscape added it as an unofficial way to signal loop count, and it stuck around as the de facto standard every browser and viewer still honors today. It stores a single 2-byte number — 0 means "loop forever," any other value means "loop exactly that many times." Because it's technically an optional application extension rather than a required part of the format, many GIF encoding libraries treat it as something to add only if a caller explicitly asks for it, and default to leaving it out or writing a loop count of 1 otherwise. Some tools also strip application extensions entirely during size-optimization passes, discarding the loop block along with genuinely redundant data. Since the visual frames are completely unaffected, this failure is easy to miss until you actually watch the exported file loop.

pixeltools' /resize and /crop tools run animated GIFs through a shared pipeline built specifically to preserve looping animation instead of collapsing it into a single static frame. Every frame is decoded with disposal-aware compositing — frames that are meant to clear back to a background color between steps are handled correctly, not just naively stacked on top of each other — then re-encoded into a fresh GIF. On every single frame written during that re-encode, the pipeline explicitly sets the loop instruction to "loop forever," rewriting the NETSCAPE2.0 extension rather than leaving it out. That means a GIF resized or cropped with pixeltools always comes out looping infinitely, regardless of whether the loop block in the original file was intact, missing, or already broken by an earlier tool. If your GIF has stopped looping after some other step in your workflow, running it through /resize or /crop rebuilds that missing instruction.

Because the loop instruction is set to "loop forever" unconditionally on every export, pixeltools' resize and crop tools cannot preserve a deliberately limited loop count. If your original GIF was authored to loop a specific number of times — a common choice for autoplaying marketing GIFs embedded on a page, meant to stop looping after a few cycles rather than run forever — resizing or cropping it with pixeltools will override that back to an infinite loop. This is a real, disclosed trade-off, not an oversight: the tool always fixes a broken (single-play) loop, but it does not read and carry forward a custom loop count from the source file. If you specifically need a limited loop count preserved, resize or crop the file first, then set the loop count back down afterward with a tool built for that specific job.

If you already have a GIF that plays once and stops, the fix is to re-encode it with a tool that rewrites the loop extension correctly, rather than trying to edit the existing file's metadata by hand. Uploading the broken GIF to /resize and exporting it — even at the same dimensions, if you don't actually need to change the size — decodes every frame, recomposites it, and re-encodes with the loop instruction set to "loop forever." You don't need access to whatever loop metadata the original source file had; the fix is applied fresh on export, not by reading and preserving what was there before. /crop works the same way if you're already cropping the file for another reason. Either way, the output is a new GIF file that loops correctly, built from the frames of the broken one.

The only reliable way to check is to preview the exported file somewhere it actually animates on repeat — a browser tab, an image viewer, or wherever it's going to be used — and watch it play past the first cycle. File size, frame count, and the thumbnail preview most editors show tell you nothing about loop count, because that information lives entirely in the extension block, separate from the visible frame data. This is exactly why the problem is easy to ship without noticing: a resized or converted GIF looks identical to the original in every editor and file browser, and the only symptom is behavioral, showing up only once someone actually watches it play twice. If you're publishing a GIF anywhere it needs to auto-loop — a marketing email, a social post, a prototype — give it one real playback check after resizing, not just a visual glance at the first frame.