WebP File Inspector

How to use

1. Drop a .webp file onto the box. Anything the extension covers works: a photo, a sticker with transparency, an animation, or a file you suspect is broken.
2. Read the file shape first. Simple lossy, simple lossless and extended are three different layouts, and a decoder that only understands the simple forms will refuse the third.
3. Compare the declared canvas with what this browser decoded. They should match; if the browser refused the file entirely, the findings list says why.
4. Open the chunk table for the layout: fourcc, offset, declared size and whether a pad byte follows. The offsets are where to look if you are debugging a writer.
5. For an animation, check the frame table — offsets are already doubled back from the halved field — and the durations, where a 0 ms frame is played as 100 ms by Chrome.

Frequently asked questions

Why does one .webp start with a VP8 chunk and another with VP8L or VP8X? Are they the same format?

They share a container and an extension, not a bitstream. The simple lossy form wraps one VP8 key frame — the same intra frame a VP8 video would start with — and the simple lossless form wraps a VP8L stream, which is an entirely different codec with its own entropy coding and colour transforms. The extended form puts a VP8X chunk first so the file can also carry alpha in a separate ALPH chunk, an ICC profile, Exif, XMP or an animation, and only then the image data. That is why an old decoder can open one WebP and reject the next: support for the simple forms arrived in 2010 and the extended form in 2011, and libraries added them at different times. The fourcc of the first chunk is the only thing that decides which shape you have.

The frame offsets in an animation look like half of what they should be. Why?

Because that is literally what is stored. An ANMF header holds the frame’s X and Y as 24-bit values that are the real offset divided by two, which is also why a frame can only be placed at an even coordinate. A reader that prints the field verbatim shows a frame at x=8 as x=4, and a compositor that uses the raw field draws every frame at half the distance from the canvas edge — a bug that looks like a subtle drift rather than an obvious break. The same header stores width and height minus one, so a 32-pixel-wide frame is written as 31. This tool doubles the offsets and adds one to the sizes before showing them, which is why the numbers here match what a decoder actually paints.

What happens to a frame that declares a duration of 0 ms?

It is not shown for zero time. Chrome and the other Blink-based browsers substitute 100 ms for a WebP frame whose duration is 0, the same substitution they make for a GIF frame with a very small delay, on the theory that a zero was a mistake rather than a request for an infinitely fast animation. Firefox and Safari have not always agreed, and command-line tools such as ffmpeg keep the zero and produce a different frame rate. The practical consequence is that the sum of the declared durations is not how long the file plays: this tool shows both totals so you can see how far apart they are before you rely on the timing.

The canvas and the image inside it are different sizes. Will the browser stretch or letterbox it?

Neither, for a still image. libwebp requires the VP8X canvas to equal the dimensions of the single VP8 or VP8L frame it contains, and refuses the file when they disagree — and since Chrome, Firefox and Safari all decode WebP with libwebp, a mismatched still simply does not display anywhere. For an animation the rule is different and the canvas is genuinely allowed to be larger: each ANMF frame is composited at its own offset, and anything extending past the canvas edge is clipped. That is why this tool treats a canvas-versus-bitstream disagreement on a still as a finding and reports frames that overflow the canvas separately.

Why does the RIFF size field matter if the file plays anyway?

It only plays anyway if the field is right. The four bytes at offset 4 must hold the file size minus eight — the eight being the RIFF fourcc and the size field itself — and libwebp validates that before it decodes anything. A download that stopped early keeps its original size field while losing bytes off the end, so the field is too large and the file is rejected with no message beyond a broken image icon. The opposite case is a writer that forgot to go back and patch the field after appending metadata, which produces a file that some tools read and browsers do not. This tool prints both numbers so you can see which of the two you have, and it separately flags any bytes sitting after the last chunk.

How is transparency stored, and why does the same picture sometimes have an ALPH chunk and sometimes not?

There are three arrangements. A lossless file records alpha inside the VP8L stream itself and just sets a hint bit in its header. A lossy file cannot, because VP8 has no alpha channel at all, so the encoder emits an extended file: a VP8X with the alpha flag set, an ALPH chunk holding the alpha plane — compressed losslessly, and optionally filtered horizontally, vertically or by gradient — and then the VP8 chunk with the colour. An animation repeats that per frame, so some frames can carry ALPH and others not. One more thing worth knowing: a lossy encoder normally throws away the colour of fully transparent pixels to save bytes, which is invisible until something composites or blurs the image, and libwebp’s `exact` option is what preserves it.

Related tools