GIF Analyzer — Frames, Delays, Palette and File Size, No Upload

Q: What is the difference between the two frame views?

The canvas after each frame is what a viewer shows at that moment: this frame drawn on top of whatever the frames before it left behind. Only what each frame stores is the rectangle the file actually holds for that frame, on its own, with nothing underneath. The second is the interesting one. A GIF may store a frame as only the part of the picture that changed, which is why a screen recording of a mostly-still window can be small. If every frame in your file is the full canvas, nothing did that work - and you cannot tell by watching the animation, only by looking at what is stored.

Choose a GIF

Drop a GIF here or click to browse — animated or still, any size

Where the bytes went

Every byte of the file is in exactly one row, and the rows add up to the file. If they did not, the last row would say so rather than the bar quietly stretching to fit.

Where this file's bytes went
Part	Bytes	Share
The whole file	—	100%

Drawing {name}: {done} of {total} frames… Analysis cancelled. The native file read may still finish. The screen or a frame has no drawable size. Drawing would exceed this page’s estimated 512 MiB buffer limit. Drawing reached the 300-million decoded-pixel limit. Drawing was cancelled. Drawing stopped: {detail} {drawn} of {total} frames drawn. {why} Header, timing and byte analysis remains available; pixel-use totals are unknown for undrawn frames. Browser playback is off because drawing is incomplete. The parsed analysis remains available. Not fully measured The tables declare {declared} colour entries. Complete pixel-use totals are unavailable while some frames are not drawn. {entries}, {size}, shared by {frames}. No entries are marked unused because not all pixels were drawn. {index}: {colour} — never used Drawing {drawn} of {total} frames drawn. {why} Undrawn frames are described from headers; pixel-use totals are unavailable. Your browser's own decoder, playing the file as it stands. Reading {name}… {name} is not a GIF: {why}. This tool reads the GIF format itself, so it has nothing to say about other files. {name} could not be read: {why} the file ends at {available} bytes and {wanted} more were needed at {at} this file starts with {what}, not “GIF” a JPEG a PNG a RIFF file — a WebP or a WAV a PDF a zip file the bytes {bytes} the code size is {size}, and the format allows 2 to 8 {n} frame {n} frames {n} colour {n} colours {n} entry {n} entries {n} per-frame table {n} per-frame tables {n} time {n} times {n} bytes {minutes}m {seconds}s {n}s {time} ({fps} fps) {n} frames ask for less than 0.02s and every browser holds them for 0.10s instead. once — no loop block forever {n} times Problem Worth knowing Note {frames}. {drawn} are drawn here; the rest are reported from their headers alone. {frames}, none of them covering the whole canvas. {frames}, all of them covering the whole canvas. {frames}, {n} of them covering the whole canvas. Show the other {frames} What frame {n} stores, on its own The canvas after frame {n} Frame {n} not drawn Delay {delay} → 0.10s Rectangle ⁦{width} × {height}⁩ at ⁦{left}, {top}⁩ Palette {n} of its own the global one none at all Transparent index {n} no Size {size} — {share} Interlaced yes Compressed {ratio}× Trouble the data ends early The tables in this file declare {declared} between them, the pixels refer to {referenced} of those, and {different} of those are different from each other. {entries}, {size}, shared by {frames}. Faded entries are ones no pixel ever refers to. {tables} ({size} in total) Frame {n} — {colours} The first 24 of {n} are shown. The rest are in the downloadable report. Comment Plain text Extension {code} A comment. No viewer shows it, and every copy of the file carries it. The loop block, saying to play forever. It is not part of the GIF specification: Netscape invented it in 1995 and everything implemented it anyway. The loop block, saying to play {times}. An XMP packet: the XML an image editor writes to record what it did. Nothing draws it. An ICC colour profile, saying what the palette’s numbers mean as colours. Almost nothing reads one out of a GIF. A plain-text block, which asks the viewer to draw text over the picture. It was in the 1989 specification and was never implemented by anything. An application block. Viewers skip the ones they do not recognise. Runs for {time} as written Actually plays {time} - {n} frame(s) below 0.02s are clamped to 0.10s by every browser Rate {fps} frames a second Loops no loop block - plays once Global palette {n} colours none Colours drawn Background index Copied. It is plain text, and it went to your clipboard only. This browser would not let the page write to the clipboard. Use “Download it” instead. Header and screen descriptor The signature, the canvas size, and the flags. Thirteen bytes, in every GIF ever made. Global colour table {colours} colours at three bytes each, shared by every frame that does not bring its own. This file has none: every frame carries its own palette. Per-frame colour tables A palette of its own for a frame that needed different colours. Three bytes a colour, every time. Frame timing blocks Eight bytes per frame: the delay, the disposal method, and which colour is transparent. Frame descriptors Eleven bytes per frame: where the rectangle sits, how big it is, and the compressor’s starting code size. Compressed pixels The picture itself, LZW-compressed. On a healthy GIF this is nearly all of the file. Block framing One length byte for every 255 bytes of data, plus a zero to end each run. Unavoidable, and worth seeing. Comments and metadata Loop blocks, comments, colour profiles, and any XMP an editor left behind. Trailer One byte saying the file is over. Bytes after the end Data sitting past the trailer. No decoder reads it, and it is pure weight. Not accounted for Bytes inside blocks this reader stopped at. A file that ends mid-block leaves some. Counted twice The blocks overlap, which means this file disagrees with itself about where they start. Unspecified Leave it in place Clear back to the background Restore what was underneath Reserved ({n}) Disposal GIF analysis — {name} Read entirely in a browser by abox.tools/gif-analyzer/. The file was not uploaded. The file Version Canvas ⁦{width} x {height}⁩ pixels Size {rounded} ({exact}) Frames Where the bytes went Total What stands out The frames Text carried in the file The global palette {colours} local global full canvas # at size delay disposal palette bytes The file ends without a trailer byte, so it is incomplete — a download that stopped early, or a file cut short. Byte {at} is 0x{marker}, which is not the start of any block this format has. Everything after it was ignored. Two graphic control blocks in a row, at {first} and {second}. The first one describes no image and does nothing. The file ends in the middle of a block that starts at {at}. {detail}. Code {code} came first, before the dictionary held anything. A viewer will draw what it can and leave the rest of the rectangle blank. Code {code} refers to dictionary entry {code}, and only {entries} exist. A viewer will draw what it can and leave the rest of the rectangle blank. There are no frames in this file. The header parsed, but no image block followed it. Whatever this is, no viewer will draw anything from it. The file does not end cleanly. {bytes} sit after the end of the file. Every decoder stops at the trailer byte, so these are never read and never drawn. They are usually a second file appended to the first, or an editor that wrote past itself. Cutting the file at the trailer loses nothing. One frame asks to be held for less than 0.02 seconds, and no browser will do it. {count} frames ask to be held for less than 0.02 seconds, and no browser will do it. Every browser since Netscape rounds a delay under two hundredths of a second up to ten — a rule written in 1996 for the spinning globes of the time and never removed. So this animation says it runs for {nominal} and actually plays for {real}, about {factor} times slower. Writing 0.02 instead of 0.01 gets the speed it was asking for. Every frame has a delay of zero. The file gives no timing at all, so what it plays at is entirely up to the viewer — usually ten frames a second, but nothing guarantees it. Two different browsers can play this at two different speeds and both be right. The frames are not evenly timed: {delays} different delays, from {shortest} to {longest}. A held final frame is deliberate and common. A scatter of delays through the middle is usually a converter dropping frames from a video and stretching the neighbours to cover the gap. There is no loop block, so this plays once and stops. Looping is not part of the GIF specification. It is a block Netscape invented in 1995 that everything implemented anyway, and a file without one is a file every browser shows exactly once. If this was meant to loop, whatever wrote it left the block out. This plays once and then stops. This plays {count} times and then stops. The loop block names a count rather than the usual zero, which means forever. Some older viewers ignore the count and loop anyway. Every frame redraws the whole canvas. A GIF may store a frame as only the rectangle that changed since the last one, which is why a screen recording of a mostly-still window can be small. Nothing here does: every frame is the full ⁦{width}×{height}⁩. That is correct for frames made from unrelated pictures, and is money left on the table for anything filmed or recorded, where most of the picture does not move between frames. One frame of {total} redraws the whole canvas; the rest store only the part that changed. {count} frames of {total} redraw the whole canvas; the rest store only the part that changed. That is what an optimised GIF looks like. The full-canvas ones are usually the first frame and any point where the picture changed completely. No frame redraws the whole canvas. Every frame after the first stores only the rectangle that changed, which is the format used properly and is why this file is as small as it is. One frame reaches outside the canvas. {count} frames reach outside the canvas. The canvas is ⁦{width}×{height}⁩ and a frame claims a rectangle that runs off the edge of it. Decoders disagree about what to do with the overhang: some clip it, some refuse the file. The canvas is ⁦{width}×{height}⁩ and some frames claim a rectangle that runs off the edge of it. Decoders disagree about what to do with the overhang: some clip it, some refuse the file. One frame carries a colour table of its own, costing {bytes} — {share} of the file. {count} frames carry a colour table of their own, costing {bytes} — {share} of the file. A palette of its own lets a frame use colours the shared table does not have, and costs three bytes per entry every time it is written. Where the frames are of the same scene, one table for all of them is both smaller and steadier to watch: a palette that lurches between frames is what GIF flicker actually is. There is no global colour table. Nothing is wrong with that — every frame here brings its own — but it does mean a viewer has nothing to paint the canvas with before the first frame arrives. {entries} colour table entries are never used, which is {bytes}. The tables in this file declare {declared} colours and the pixels refer to {referenced} of them. A colour table is a power of two entries long whatever is in it, so a frame using nine colours still gets sixteen; some rounding up is unavoidable. Much more than that means the palettes were built for a different picture than the one that ended up in the frame. The whole animation draws with one colour. The whole animation draws with {count} colours. That is flat artwork, and it is what GIF was designed for. A file like this compresses well and dithers badly, so if it looks speckled the dithering is the thing to turn off. A photograph, or something rendered from one. GIF gives a frame at most 256 colours, so anything with a gradient in it is being approximated — which is where dithering, and the noise that makes a file large, comes from. There is a comment block of {bytes} in this file. Comments are not shown by any viewer and are carried by every copy of the file. They are usually the name of whatever wrote it, and occasionally something the author would not have chosen to publish. An XMP metadata packet takes up {bytes} — {share} of the file. XMP is the XML block an image editor writes to record what it did, and it can carry the edit history, the software, and sometimes the author. No viewer draws any of it. Removing it costs the picture nothing. An ICC colour profile takes up {bytes}. The profile says what the numbers in the palette mean as colours. Almost nothing reads one out of a GIF, so it is usually weight for nothing — but dropping it can shift the colours in the viewers that do. There is a plain-text extension in this file. A block that asks the viewer to draw text over the picture in a grid of cells. It was in the 1989 specification, it was never implemented by anything, and every decoder skips it. Whatever it says will not appear. There is an application block named “{name}”, of {bytes}. Application blocks are how anything outside the specification gets into a GIF. Viewers skip the ones they do not recognise, so this one is weight unless something specific is reading it. One frame is interlaced. {count} frames are interlaced. The rows are stored in four passes so that a picture arriving down a slow line showed a coarse version of itself early. It made sense in 1993, it compresses slightly worse than storing the rows in order, and no viewer benefits from it now. This file says it is GIF{version} rather than GIF89a. GIF87a came first and has no timing blocks, no transparency and no loop block. A file claiming 87a while carrying any of those is common — decoders do not check — but it is a sign the header was copied rather than written. The background colour is index {index}, and the global table only has {entries} entries. Nothing will crash — viewers use transparent instead — but it means the field was never set, or was set for a palette that is no longer the one in the file. The pixel aspect ratio is set to {ratio}. A field for displays that did not have square pixels. Every modern viewer ignores it and draws the frame at its stored size, so a file relying on it will look stretched to whoever made it and normal to everybody else. The compressor reset its dictionary {count} times. LZW builds a dictionary as it goes and can hold 4,096 entries; when it fills, the encoder starts again. Once per frame is normal — it is how a frame begins. More than that means the picture was varied enough to exhaust the dictionary partway through, which is what a photograph or heavy dithering does, and is why those files are large. One frame is identical to the frame before. {count} frames are identical to the frame before. They cost their full compressed size and change nothing on screen. Adding their delay to the previous frame instead would look exactly the same and would be smaller. One frame does not decode completely. {count} frames do not decode completely. The compressed data ends before the frame is full. A viewer will draw what it can and leave the rest of the rectangle blank. your GIF has gone nowhere. {total} files loaded. {platform} something contacted {hosts}, which this tool never does. {platform} The page's own ad, measurement and donate-button scripts loaded from {hosts} host; not one of them was given a file. The page's own ad, measurement and donate-button scripts loaded from {hosts} hosts; not one of them was given a file.

View as Markdown

# GIF Analyzer — what is actually inside a GIF

Frames, delays, palettes, and where every byte went.

> Take a GIF apart in your browser: every frame with its delay and disposal, the colour tables, the loop count, and a byte-by-byte breakdown of where the file size went. Nothing is uploaded.

This is an interactive browser tool at https://abox.tools/gif-analyzer/. Files are processed on the device running that browser. Any deliberate sharing or optional network feature is described on the page. What follows is its written explanation; open the address to use it.

## Your GIFs are **processed in your browser**. No processing upload.

The file is opened and taken apart by your own browser: the block structure, the LZW decompression and every frame drawn on this page are done on this machine. There is no server on the other end of this page to send a file to even if anything here wanted to.

- ✗ No upload
- ✗ No account
- ✓ Works offline
- ✓ Open source
- ✓ Files stay on your device

## How to analyze a GIF

1. **Choose a GIF.** Drop it onto the picker, or select it by hand. It is read straight off your disk by the browser; nothing is sent anywhere while you do it.
2. **Read the summary first.** The canvas size, the frame count, how long the animation says it runs and how long it actually plays. Those last two differ more often than people expect, and the reason is in the next section.
3. **Look at what stands out.** Every line there is measured from your file: delays no browser will honour, a missing loop block, colour tables nothing refers to, metadata that is bigger than some of the frames. Nothing is a guess about what you meant to make.
4. **See where the bytes went.** Every byte of the file is in exactly one row, and the rows add up to the file. If most of it is not in "compressed pixels", the rest of the table says where it is instead.
5. **Go through the frames.** Each one shows its delay, its rectangle, its disposal method and its size. Switch between "the canvas after each frame" and "only what each frame stores" — the second is how you see whether the file is optimised, because a well-made GIF stores tiny rectangles and a badly made one stores the whole picture every time.
6. **Take the report if you need it.** The whole analysis as plain text, to paste into a message or keep beside the file. It is built in the page from what is already on your screen.

## The longer version

[What is actually inside a GIF](https://abox.tools/guides/whats-inside-a-gif/): Frames, delays, disposal methods and colour tables explained, why browsers refuse the fastest delays, and how to work out where a GIF's file size really went.

## Also in the box

- [Remote Camera](https://abox.tools/remote-camera/): Open a camera on one device and watch it in another browser, with optional viewer approval. Live video travels directly between them, encrypted.
- [Video Compressor](https://abox.tools/compress-video/): Say how big it may be. The tool works out the rest, and measures the result before you get it.
- [MP4 Converter](https://abox.tools/convert-to-mp4/): Whatever came off the screen recorder, the ripper or the camera, as H.264 and AAC in an MP4. Copied where it can be, re-encoded only where it must.
- [Video Rotator](https://abox.tools/rotate-video/): A quarter turn, a half turn, the other way. With header rotation, the picture frames stay unchanged.

## Questions

### Is my GIF uploaded anywhere?

No. The file is read, decompressed and drawn by your own browser on your own hardware. There is no server side to this tool, and the page's `Content-Security-Policy` names every address it may contact — none of them belongs to this site. Unplug from the network and it still analyses GIFs.

### Why does my GIF play slower than the delays say?

Because every browser refuses to honour a delay under two hundredths of a second and holds the frame for a tenth instead. The rule was written into Netscape in 1996, for the spinning globes and under-construction signs of the time, and has been copied into every browser since; nothing has ever removed it. \
\
So a GIF whose frames all say 0.01s does not play at 100 frames a second. It plays at 10, which is five to ten times slower than whatever made it intended. This page shows both numbers — what the file says and what it will actually do — and marks the frames it affects. The fix, in whatever made the file, is to write 0.02 rather than 0.01.

### What does “disposal” mean?

What to leave on the screen when a frame's time is up, and it is the field that decides whether an animation looks right or smears. \
\
**Leave it in place** means the next frame paints over this one, which is what you want when frames are opaque and cover each other. **Clear back to the background** wipes the frame's rectangle first, which is what transparency needs — without it the see-through parts of the next frame show the previous one underneath. **Restore what was underneath** puts back whatever was there before this frame drew, which is how a small moving object over a still background is stored. And **unspecified** means the file did not say, and every viewer treats it as "leave it in place".

### Why is my GIF so large?

The "Where the bytes went" table answers that for your particular file rather than in general, and there are only a few possible answers. \
\
If nearly all of it is **compressed pixels**, the file is simply a lot of picture: GIF stores every frame as whole pixels, with no motion compensation and no quality dial, so the size is roughly the area times the frame count. Fewer frames, a smaller size or fewer colours are the only levers. \
\
If a large slice is **colour tables**, the file is writing a palette per frame at 768 bytes each. If a large slice is **metadata**, an editor left an XMP packet behind and it can be removed without touching the picture. And if the frames all cover the whole canvas, the encoder never worked out which part actually changed — which on anything filmed or recorded is most of the file.

### What is the difference between the two frame views?

**The canvas after each frame** is what a viewer shows at that moment: this frame drawn on top of whatever the frames before it left behind. **Only what each frame stores** is the rectangle the file actually holds for that frame, on its own, with nothing underneath. \
\
The second is the interesting one. A GIF may store a frame as only the part of the picture that changed, which is why a screen recording of a mostly-still window can be small. If every frame in your file is the full canvas, nothing did that work — and you cannot tell by watching the animation, only by looking at what is stored.

### It says my file has a comment or XMP in it. What is that?

Text that rides along with the picture and that no viewer draws. A comment block is usually the name of whatever wrote the file. An XMP packet is the XML an image editor writes to record what it did, and it can carry the edit history, the software version and sometimes the author's name. \
\
This page prints both out in full, because the interesting question about metadata is what it says rather than that it exists. It is shown to you and to nobody else: nothing in this repository reads any of it out to anyone.

### Can it open a broken GIF?

It tries, and it tells you where it gave up. A file that ends mid-block, has a byte where a block marker should be, or carries a frame whose compressed data runs out early will still show everything that was readable before that point, with the problem named at the top. That is the case an analyzer is most wanted for, so throwing the whole file away over one bad byte would be the wrong behaviour.

### Does it change my file?

No. This tool only reads. There is no output file, no re-encode and no button here that writes a GIF — the only thing you can download is a plain-text copy of the analysis. Your original is untouched on your disk, which is also the honest answer to what happens if you close the tab.

### Is it free, and do I need an account?

It is free, with no account, sign-in or trial. Reading a file still depends on your machine’s memory. Drawing stops at 300 million decoded pixels or an estimated 512 MiB of buffers owned by this page; this estimate is not a total browser-memory limit. After drawing stops or you cancel it, headers, byte accounting and timing remain available, undrawn frames are described from headers, and complete pixel-use totals and the native animation preview are unavailable. The initial parse and native memory/canvas operations cannot be interrupted mid-call. The site carries advertising; the ads receive no information about your file.

### Does it work offline?

Yes. Load the page once, then disconnect from the internet and it keeps working. That is also the simplest way to prove nothing is being uploaded: a tool that sent your GIF away to be analysed would stop the moment you unplugged.

## How the privacy claim is verifiable

- **Processing happens in this browser.** This tool processes input and results inside your browser. Its processing code does not upload them for processing. Content-Security-Policy restricts permitted resources and connection destinations, but allowed hosts can still receive requests: the policy does not inspect payloads and alone cannot prove that nothing is sent. Compare the source with the requests for the operation you use, or complete that local operation while disconnected.
- **The reader is four files in this repository.** Nothing here uses the browser's own GIF decoder to work out what is in the file, because that decoder will not say where a byte went. So the format is read out by hand: `src/gif.js` walks the blocks, `src/lzw.js` expands the pixels, `src/frames.js` stacks them, and `src/budget.js` adds the parts back up and checks they come to the size of the file.
- **Comments and metadata are shown to you, and to nobody else.** A GIF can carry a comment block, an XMP packet describing an edit, or a colour profile, and this page prints all of them out. They are put on the screen in front of you and go nowhere else: there is no analytics event in this repository that carries any of it. Optional feedback reports only the tool slug, a fixed vote and a fixed reason, never the metadata read from your file.
- **What Google loads, and what it is not given.** The ad and measurement scripts come from Google. Neither is handed anything about your file: not the file, not a thumbnail, not a name, a size, a frame count or a comment. Every line that reads, decompresses or draws a GIF is served from this origin and listed in the repository.
- **What the donate button loads, and what it is not given.** The "Buy me a coffee" button in the header is drawn by a script from cdnjs.buymeacoffee.com and letters itself from Google Fonts. It is a link and nothing more: it reports no visit, and it is handed nothing about you or your files. Nothing happens unless you click it, and what you would be clicking through to is somebody else's site.
- **It works offline.** Disconnect from the network and every part of this page still works. That is the simplest proof of all: a tool that sent your GIF away to be analysed would stop the moment you unplugged.

**Check it yourself.** None of the above has to be taken on trust. This page is generated from the templates and config in the repository by a build script you can read and run yourself, and the result is committed to the `dist` branch — so you can diff what is served against what a build of the sources produces: https://github.com/A-Box-of-Tools/website

The files worth reading first are `config/site.toml` for the Content-Security-Policy, `src/gif.js` for the block reader that walks the file, `src/lzw.js` for the decompressor, and `src/budget.js` for the byte accounting — none of which has a line that could reach the network.

How to analyze a GIF

Choose a GIF. Drop it onto the picker, or select it by hand. It is read straight off your disk by the browser; nothing is sent anywhere while you do it.
Read the summary first. The canvas size, the frame count, how long the animation says it runs and how long it actually plays. Those last two differ more often than people expect, and the reason is in the next section.
Look at what stands out. Every line there is measured from your file: delays no browser will honour, a missing loop block, colour tables nothing refers to, metadata that is bigger than some of the frames. Nothing is a guess about what you meant to make.
See where the bytes went. Every byte of the file is in exactly one row, and the rows add up to the file. If most of it is not in "compressed pixels", the rest of the table says where it is instead.
Go through the frames. Each one shows its delay, its rectangle, its disposal method and its size. Switch between "the canvas after each frame" and "only what each frame stores" — the second is how you see whether the file is optimised, because a well-made GIF stores tiny rectangles and a badly made one stores the whole picture every time.
Take the report if you need it. The whole analysis as plain text, to paste into a message or keep beside the file. It is built in the page from what is already on your screen.

The longer version

What is actually inside a GIF Frames, delays, disposal methods and colour tables explained, why browsers refuse the fastest delays, and how to work out where a GIF's file size really went.

Questions

Is my GIF uploaded anywhere?

No. The file is read, decompressed and drawn by your own browser on your own hardware. There is no server side to this tool, and the page's Content-Security-Policy names every address it may contact — none of them belongs to this site. Unplug from the network and it still analyses GIFs.

Why does my GIF play slower than the delays say?

Because every browser refuses to honour a delay under two hundredths of a second and holds the frame for a tenth instead. The rule was written into Netscape in 1996, for the spinning globes and under-construction signs of the time, and has been copied into every browser since; nothing has ever removed it.

So a GIF whose frames all say 0.01s does not play at 100 frames a second. It plays at 10, which is five to ten times slower than whatever made it intended. This page shows both numbers — what the file says and what it will actually do — and marks the frames it affects. The fix, in whatever made the file, is to write 0.02 rather than 0.01.

What does “disposal” mean?

What to leave on the screen when a frame's time is up, and it is the field that decides whether an animation looks right or smears.

Leave it in place means the next frame paints over this one, which is what you want when frames are opaque and cover each other. Clear back to the background wipes the frame's rectangle first, which is what transparency needs — without it the see-through parts of the next frame show the previous one underneath. Restore what was underneath puts back whatever was there before this frame drew, which is how a small moving object over a still background is stored. And unspecified means the file did not say, and every viewer treats it as "leave it in place".

Why is my GIF so large?

The "Where the bytes went" table answers that for your particular file rather than in general, and there are only a few possible answers.

If nearly all of it is compressed pixels, the file is simply a lot of picture: GIF stores every frame as whole pixels, with no motion compensation and no quality dial, so the size is roughly the area times the frame count. Fewer frames, a smaller size or fewer colours are the only levers.

If a large slice is colour tables, the file is writing a palette per frame at 768 bytes each. If a large slice is metadata, an editor left an XMP packet behind and it can be removed without touching the picture. And if the frames all cover the whole canvas, the encoder never worked out which part actually changed — which on anything filmed or recorded is most of the file.

What is the difference between the two frame views?

The canvas after each frame is what a viewer shows at that moment: this frame drawn on top of whatever the frames before it left behind. Only what each frame stores is the rectangle the file actually holds for that frame, on its own, with nothing underneath.

The second is the interesting one. A GIF may store a frame as only the part of the picture that changed, which is why a screen recording of a mostly-still window can be small. If every frame in your file is the full canvas, nothing did that work — and you cannot tell by watching the animation, only by looking at what is stored.

It says my file has a comment or XMP in it. What is that?

Text that rides along with the picture and that no viewer draws. A comment block is usually the name of whatever wrote the file. An XMP packet is the XML an image editor writes to record what it did, and it can carry the edit history, the software version and sometimes the author's name.

This page prints both out in full, because the interesting question about metadata is what it says rather than that it exists. It is shown to you and to nobody else: nothing in this repository reads any of it out to anyone.

Can it open a broken GIF?

Does it change my file?

Is it free, and do I need an account?

Does it work offline?

GIF Analyzer — what is actually inside a GIF

How the privacy claim is verifiable

Choose a GIF

What stands out

Where the bytes went

The colours

The global table

What else is in there

How to analyze a GIF

The longer version

Questions

How the privacy claim is verifiable

Choose a GIF

—

What stands out

Where the bytes went

Frame by frame

The colours

The global table

What else is in there

How to analyze a GIF

The longer version

Also in the box

Questions