About the GIF Viewer
Double clicking a GIF usually opens a photo app that shows the animation and tells you nothing else. This viewer plays the file and prints the numbers underneath: logical canvas size, how many frames the stream contains, the total time one loop takes, the average frame rate that works out to, whether a global palette exists and how many colours it holds, and whether any frame declares a transparent index.
The repeat setting comes from the Netscape application extension. When that block is missing the report says so, which explains the classic complaint that an animation plays once in one program and forever in another. Nothing in the base GIF specification says a file should loop, so the two behaviours are both defensible and the extension is the only thing that settles it.
Below the table sits a strip of composited thumbnails with each frame number and delay, which is the quickest way to find the frame where an artefact appears or where a palette shift causes a colour to jump. A delay of zero is worth noticing: encoders write it when no timing was given, and browsers silently substitute roughly one hundred milliseconds, so an animation can run at a different speed than its author intended. When you need the frames as files rather than a report, GIF Splitter exports them.
How to use
- Drop a .gif onto the left pane to load it.
- Read the table for canvas size, frame count, loop time and palette details.
- Scan the thumbnail strip to find a specific frame by its number and delay.
- Press Download to keep the report as a text file.
Common questions
- What does a repeat value of forever mean?
- It means the file carries a Netscape looping block set to zero, which every browser reads as an endless loop.
- Why does the report say a frame has no delay?
- The encoder left the delay field at zero. Browsers then apply a default of about one hundred milliseconds, so the animation runs slower than the raw numbers suggest.
- Can this viewer open a GIF that other apps refuse?
- Often yes, because the frames are parsed here rather than handed to the operating system decoder. A truncated file still shows every frame that was recovered before the damage.
- Does the tool change the GIF in any way?
- No. The original bytes are read and displayed, and nothing is written back or sent anywhere.