WebP file format
Google's WebP format, a RIFF container for lossy or lossless images.
- MIME type
- image/webp
- Extensions
- .webp
- Category
- Images
Magic-number signature
| 0x00000000 | 52494646 | RIFF | RIFF container |
| 0x00000008 | 57454250 | WEBP | 'WEBP' form type |
About the WebP format
WebP offers both lossy and lossless modes plus animation and transparency, typically beating JPEG and PNG on size. It is a RIFF container: the bytes 'RIFF', a four-byte length, then the form type 'WEBP'. What follows is one chunk, or several, and which one appears first decides everything about the file — a simple lossy image is a single VP8 chunk, a simple lossless image is a single VP8L chunk, and anything with an alpha channel, animation, an ICC profile or metadata is a VP8X chunk that declares those features and is followed by the chunks that supply them.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 4 | RIFF container tag | 52 49 46 46, the ASCII letters RIFF. Not unique to WebP by any means — AVI and WAV open with exactly the same four bytes — so nothing about the format is established until offset 8 has been read as well. |
| 4 | 4 | RIFF payload size | Little-endian byte count of everything after this field, which is the file size minus eight. Unlike most size fields this one is expected to be exact, so comparing it against the length on disk costs four bytes to read and catches truncation and careless appending immediately. |
| 8 | 4 | WEBP form type | 57 45 42 50. This is the field that separates a WebP from every other RIFF file, and together with the tag at offset 0 it is the format's real magic number: twelve bytes with a variable four in the middle. |
| 12 | 4 | First chunk FourCC | Three variants and nothing else is legal here. 56 50 38 20 is VP8 with a trailing space, a simple lossy image. 56 50 38 4C is VP8L, a simple lossless image. 56 50 38 58 is VP8X, the extended form used whenever alpha, animation, Exif, XMP or an ICC profile is present. |
| 16 | 4 | First chunk payload size | Little-endian length of the chunk data that follows, not counting the eight bytes of FourCC and size. RIFF pads every chunk to an even length and the pad byte is not counted here, which is the detail that misaligns hand-written parsers on odd-sized chunks. |
| 20 | 3 | VP8 frame tag — simple lossy only | Three bytes of packed bitfields opening the VP8 bitstream: the low bit says key frame or interframe, three bits give the profile, one bit is show_frame and the remaining nineteen bits are the size of the first data partition. In a still WebP it is always a key frame. |
| 23 | 3 | VP8 key-frame start code — simple lossy only | The constant 9D 01 2A. It is the closest thing to a second signature the format has, and finding it at offset 23 confirms both that the file is lossy WebP and that its first chunk header was the expected size. |
| 26 | 4 | VP8 width and height — simple lossy only | Two little-endian 16-bit values, width then height. Only the low fourteen bits of each are the dimension; the top two bits are a horizontal or vertical scale hint that essentially nothing implements. Fourteen bits is why a single VP8 frame cannot exceed 16383 pixels on a side. |
| 20 | 1 | VP8L signature byte — simple lossless only | The constant 2F. Immediately after it the width minus one and the height minus one are packed as fourteen bits each in a bit stream, so unlike every other field on this page they do not sit on byte boundaries and cannot be read from a hex dump without shifting. |
| 20 | 4 | VP8X flags and reserved bytes — extended only | One flags byte then three reserved zero bytes. The flags announce, from bit 5 downward, an ICC profile, an alpha channel, Exif metadata, XMP metadata and animation. They are a declaration, not the data: each feature is supplied by its own chunk later in the file. |
| 24 | 6 | VP8X canvas size — extended only | Canvas width minus one and canvas height minus one as two 24-bit little-endian values, allowing a canvas far larger than a single VP8 frame can be. In an animation this is the canvas the frames are composited onto, and individual frames carry their own offsets and sizes. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| AVI | Identical for the first eight bytes, because both are RIFF files. The form type at offset 8 is the whole test: 57 45 42 50 for WebP, 41 56 49 20 for AVI with a trailing space. A tool that matches only 52 49 46 46 will happily label a video an image, which is exactly the mistake to check for when a detector reports the wrong category. |
| WAV | The same RIFF trap in the other direction: 57 41 56 45 at offset 8. Worth naming explicitly because WAV, AVI and WebP are the three RIFF formats anyone actually meets, they span audio, video and image, and they are indistinguishable until the ninth byte. |
| PNG | 89 50 4E 47 against 52 49 46 46. They compete directly for lossless images with alpha, and lossless WebP normally wins by around a quarter on file size. The catch is that a lossless WebP with transparency is a VP8X file with a separate ALPH chunk, so its structure has nothing in common with the simple lossy form described above. |
| GIF | An animated WebP is not a separate format: it is a VP8X file with the animation flag set, an ANIM chunk giving the background colour and loop count, and one ANMF chunk per frame. It replaces GIF at a fraction of the size with full alpha instead of a single transparent index, which is why so many platforms now transcode uploads and keep serving them from .gif URLs. |
How these files break
- A stale RIFF size at offset 4. Appending to a WebP without updating that field produces a file where strict readers stop at the declared length and lenient ones keep walking chunks to the end of the data, so the same image shows metadata in one tool and not in another. It is the usual result of concatenating files with a shell redirect.
- Truncation. The twelve-byte container header and the chunk header survive, so dimensions read correctly and the top of the picture decodes before the VP8 partition runs out; the bottom is left as flat grey or green. The size field at offset 4 will exceed the actual file length, which confirms it in four bytes.
- A missing pad byte after an odd-length chunk. RIFF requires chunks to be padded to an even length, and a writer that forgets leaves every subsequent chunk header offset by one. The first chunk still decodes, so the image appears and its ICC profile or Exif block silently vanishes.
- Served or renamed with the wrong extension. Social and messaging apps hand out WebP under .jpg names constantly, so a file that will not open in an older desktop editor is very often undamaged WebP. Offset 0 settles it in four bytes, and re-encoding is unnecessary — renaming is enough.
- A VP8X header that promises features the file does not contain. If the alpha flag is set but no ALPH chunk follows, decoders disagree: some render the image opaque and some refuse it outright. Nothing about the byte layout is invalid, which is why validators pass it.
Where the format stands today
WebP is the default modern delivery format for images on the web and has been since Safari 14 in 2020 gave it universal browser support. It sits in the useful middle of the field: roughly a quarter to a third smaller than JPEG at matching quality, a lossless mode that beats PNG, alpha and animation in one container, and encoding fast enough to run on demand in a CDN or an image server rather than only in a nightly build. AVIF compresses better and HEIC is what phones capture, but neither is as cheap to produce or as safely assumed present. Its limits are real and worth knowing before committing: eight bits per channel only, so no HDR and no wide-gamut delivery, chroma subsampling forced on in the lossy mode, and a single frame capped at 16383 pixels a side. For photographic content on a site that needs one format and no fallback logic, it is the correct answer today; for the best possible compression with a picture element and fallbacks already in place, AVIF first and WebP second is the standard arrangement.
Open WebP files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with WebP — compare their leading bytes.