GIF Inspector

Choose the .gif file and GIF Inspector immediately shows the frame count, the total duration and a frame table with every delay in centiseconds and milliseconds side by side. Each row also gives the frame's position and size, disposal method, transparent colour index, interlace flag and LZW minimum code size. The total duration is the plain sum of the delays stored in the file.

No upload is needed: the GIF is read inside your browser tab and the report is assembled there, so the file is not sent to a server to be analysed. Web addresses that appear inside a comment are displayed as plain text and are never opened, and the downloadable JSON report is generated in the same tab.

Yes. The inspector runs in a current browser on iPhone, Android, macOS and Windows, so you can pick a GIF from Files or Downloads and get the same report without installing an app. Some messaging apps save animated "GIFs" as MP4 or WebP; if that happens the tool reports that the file is not a GIF instead of guessing.

The first three bytes of the file are not "GIF", which means the content is another format carrying a .gif name—often a WebP, PNG, MP4 or an HTML page saved by mistake. The check looks at the bytes, not the extension. A file that starts with GIF but has a version other than 87a or 89a is reported as an unsupported version, and one shorter than a complete header is reported as truncated.

Both mean the file stops before the GIF structure is finished, usually because a download or copy was interrupted, and the report lists everything read up to the byte offset where it stopped. Frames parsed before the break stay in the frame table. A warning that a sub-block length runs past the end of the file points to the same kind of damage; fetching the original again is the most reliable fix.

Files up to 30,000,000 bytes (about 30 MB) are accepted, and parsing stops with a warning after 20,000 frames or 100,000 extension blocks. The on-page frame table shows the first 5,000 frames, while the downloadable JSON report contains every frame that was parsed. Comment and plain text content is kept up to 200,000 bytes in total and marked truncated beyond that.

The inspector reports the delay exactly as the file stores it, so 0 stays 0 ms and the total duration is not adjusted. Many browsers stretch delays of 0 or 1 centisecond to roughly 100 ms, so playback of either can be slower than the numbers. Only frames stored with a delay of exactly 0 are flagged as zero-delay and carry the browser clamping note; a 1-centisecond frame simply shows 10 ms with no flag, and no value is ever changed.

No. It describes how the GIF is put together but makes no judgement about safety, authenticity, editing history or AI generation, and it does not scan for malware. Bytes after the trailer are counted without guessing their purpose, and unknown extensions are listed only by their hex label. Use security software or a trusted source when you need a safety verdict.

GIF89a introduced extension blocks for frame delays, transparency, comments and the NETSCAPE loop count; GIF87a has none of them, so its report says no animation extensions were found instead of inventing default values. If a file labelled 87a does contain extensions, the tool flags that mismatch so you can see the label and the content disagree.

Check the loop count, which is read from the NETSCAPE2.0 application extension: 0 means the GIF loops forever and any other number is the stored repeat count. When the file has no such block, no loop count is shown because the file carries no loop instruction. A NETSCAPE2.0 data block that is not the expected three bytes is flagged as malformed and the loop count stays empty; a three-byte block whose sub-block ID is not 1 is not a loop instruction, so the loop count also stays empty, but without a warning. The value is never guessed.

Comment extensions get their own table showing the text decoded as Latin-1, a strict UTF-8 reading when the bytes are valid UTF-8, and the raw byte length. GIF comments declare no encoding, so both readings are offered instead of one presented as fact. NUL and other control bytes appear as \xNN escapes, except tab, line feed and carriage return (0x09, 0x0A, 0x0D), which are kept as ordinary whitespace; any markup in a comment is shown as literal characters.

No. It only reads the GIF and never rewrites, optimises or re-encodes it; the one file you can save is the JSON report of its structure, named after the original GIF. For resizing, compressing or changing format you need a separate converter, and this report can help you compare the before and after.