WEBP File Documentation

Summary

A WebP Image is a raster image format from Google that compresses smaller than JPEG or PNG at similar quality and also supports transparency and animation. It was introduced in 2010, wraps its data in a RIFF container starting with 52 49 46 46 (“RIFF”) then 57 45 42 50 (“WEBP”), and its MIME type is image/webp. A .webp opens in any modern browser, the Windows 11 Photos app and macOS Preview.

Technical details

FeatureValue
Full nameWebP image
File extension.webp
MIME typeimage/webp
Format typeRIFF-container raster image
Container / base formatRIFF (chunk-based, same container as WAV and AVI)
DeveloperGoogle
Introduced2010 (lossy); lossless + alpha 2011; animation 2012
Open standardYes — open spec, open-source libwebp
Byte orderLittle-endian (RIFF)
Lossy codecVP8 intra-frame coding (VP8  chunk)
Lossless codecVP8L (VP8L chunk)
Extended formVP8X chunk with a feature-flags byte
TransparencyYes — alpha via lossless, or ALPH chunk in extended files
AnimationYes — ANIM + per-frame ANMF chunks
Metadata / colourICCP (ICC profile), EXIF, XMP chunks
Max dimensions16383 × 16383 pixels
Magic number52 49 46 46 … 57 45 42 50 (“RIFF” … “WEBP”)
Related extensions.png, .jpg, .gif, .avif, .heic
Specificationdevelopers.google.com/speed/webp/docs/riff_container
File signature (magic bytes)
52 49 46 46 <size> 57 45 42 50

Bytes 0–3 are RIFF (52 49 46 46). Bytes 4–7 are a little-endian 32-bit file size (total bytes minus 8). Bytes 8–11 are WEBP (57 45 42 50), the form type that identifies this RIFF file as an image. The next FourCC names the variant: VP8  (lossy), VP8L (lossless) or VP8X (extended: alpha, animation, ICC, EXIF/XMP). Every chunk is FourCC + 32-bit size + payload, padded to an even byte count.

What is a WebP file?

WebP is a raster image format Google released in 2010 to make web pages load faster by shrinking image sizes. A .webp file can hold a photograph compressed lossily (smaller than an equivalent JPEG), a graphic compressed losslessly with transparency (replacing PNG), or an animation (replacing GIF), all under one extension. Lossless mode and an alpha channel were added in 2011, animation in 2012. It is an open standard with a published specification and the open-source libwebp reference library. Its MIME type is image/webp.

Two things make WebP worth examining at the byte level. First, it is not a single codec but a small family, lossy VP8, lossless VP8L, and an extended form, wrapped in a shared container. Second, that container is RIFF, the same chunk-based structure used by WAV and AVI, which means a WebP is a sequence of tagged chunks a parser can walk. The sections below cover the RIFF header, the three chunk kinds, how the two codecs differ, and how alpha and animation are layered on top.

The RIFF container: RIFF, size and WEBP

Every WebP begins with a 12-byte RIFF header:

offset 0:  52 49 46 46            "RIFF"   (container magic)
offset 4:  ss ss ss ss            file size − 8, little-endian uint32
offset 8:  57 45 42 50            "WEBP"   (RIFF form type)

Bytes 0–3 are the ASCII tag RIFF. Bytes 4–7 are a 32-bit little-endian integer giving the size of everything after this field, i.e. the total file size minus 8. Bytes 8–11 are the form type WEBP, which is what marks this particular RIFF file as a WebP image rather than a WAV or AVI. After this header comes a series of chunks. Each chunk has the same shape: a four-character code (FourCC), a 32-bit little-endian size, then that many bytes of payload. If the payload length is odd, a single padding byte is added so the next chunk starts on an even offset. RIFF is little-endian throughout, which is one of the ways WebP differs from big-endian formats like PNG.

The three chunk kinds: VP8, VP8L and VP8X

The FourCC of the first chunk after WEBP tells a decoder which of three forms the file takes.

First chunkFormMeaning
VP8 Simple lossyA single VP8 key frame; no alpha, no animation
VP8LSimple losslessVP8L bitstream; may carry alpha internally
VP8XExtendedA feature-flags header followed by further chunks

Note the trailing space in VP8  (hex 56 50 38 20): FourCCs are always four bytes, so the three-character name is padded with a space. A simple file (either VP8  or VP8L) contains just that one image chunk and nothing else, which is the compact common case for a plain photo or graphic. An extended file starts instead with a VP8X chunk and then lists additional chunks for the features it uses.

The VP8X feature-flags byte

The VP8X chunk is a 10-byte header that declares which optional features the file uses. Its first byte is a set of feature flags; reserved bits are zero.

VP8X payload (10 bytes):
  byte 0: flags   bit layout (from MSB):  Rsv Rsv I L E X A Rsv
                    I = ICC profile present   (ICCP chunk)
                    L = alpha present         (ALPH chunk or VP8L alpha)
                    E = EXIF metadata         (EXIF chunk)
                    X = XMP metadata          (XMP  chunk)
                    A = animation present     (ANIM/ANMF chunks)
  bytes 1-3: reserved
  bytes 4-6: canvas width  − 1  (24-bit little-endian)
  bytes 7-9: canvas height − 1  (24-bit little-endian)

The flags tell a decoder, before it reads the rest of the file, whether to expect an ICCP colour-profile chunk, an ALPH alpha chunk, EXIF or XMP metadata, and animation chunks. The canvas dimensions are stored minus one, which is why the maximum WebP size is 16383 (that is 214 − 1) in each direction. The order of the chunks that follow VP8X is defined by the specification: colour profile first, then animation or the still-image data, then metadata.

How VP8 and VP8L differ

The two codecs inside WebP are unrelated compression schemes, which is why the format needs distinct chunk types for them.

VP8 (the lossy path) borrows the intra-frame coding of the VP8 video codec. A lossy WebP is essentially a single VP8 key frame: the image is split into macroblocks, predicted from neighbouring blocks, transformed (a 4×4 integer DCT-like transform plus a Walsh-Hadamard transform for the DC coefficients), quantised, and entropy-coded with a boolean arithmetic coder. Because it works in the YUV colour space with chroma subsampling and discards high-frequency detail, it compresses photographs tightly but loses information, like a smarter JPEG. Google reports lossy WebP is typically 25–35% smaller than a comparable JPEG.

VP8L (the lossless path) is a completely separate design aimed at exact reproduction. It works in RGB, and applies reversible transforms before entropy coding: a predictor (spatial) transform that codes each pixel as a residual from a prediction of its neighbours, a colour transform that decorrelates the R, G and B channels, a colour-indexing (palette) transform for images with few colours, and a subtract-green step. The residuals are then Huffman-coded with a form of LZ77 backward referencing. VP8L reconstructs every pixel exactly and is around 26% smaller than PNG on typical graphics.

Alpha: transparency in WebP

Transparency is handled differently depending on the codec. In a lossless VP8L file the alpha channel is part of the bitstream itself; VP8L natively encodes RGBA. In a lossy extended file, the colour data is a VP8 key frame (which has no alpha) and the transparency is stored separately in an ALPH chunk. The ALPH chunk holds the alpha plane, optionally compressed with the same lossless VP8L machinery and optionally pre-filtered, so a lossy WebP can pair a small lossy colour image with a crisp lossless alpha mask. The VP8X alpha flag signals that alpha is present. This split, lossy colour plus lossless transparency, is something JPEG cannot do at all and is a common reason to choose WebP over JPEG for images that need a transparent background.

Animation: ANIM and ANMF

An animated WebP is always an extended file. Two chunk types drive it. A single ANIM chunk holds global animation parameters: the background colour used to fill the canvas and the loop count (how many times the animation repeats, with zero meaning infinite). Then each frame is an ANMF chunk containing that frame’s own header, its position (x, y offset on the canvas) and size, its display duration in milliseconds, a disposal method (whether to clear the frame area to the background before the next frame), a blending method, and the frame’s image payload, which is itself a VP8 , VP8L or alpha sub-chunk.

VP8X (animation flag set)
 ├─ ANIM            background colour + loop count
 ├─ ANMF (frame 1)  x,y, w,h, duration, dispose/blend + image data
 ├─ ANMF (frame 2)  ...
 └─ ANMF (frame N)  ...

Because each frame can be a small rectangle placed at an offset and can reuse the previous canvas via its disposal and blend settings, only the changed region of each frame need be stored, the same delta idea that keeps animated GIF files smaller, but with WebP’s far better compression and full 8-bit alpha rather than GIF’s single transparent colour. The newer AVIF format, built on the AV1 codec, compresses better still and is WebP’s main successor pressure.

Colour profiles and metadata chunks

An extended WebP can carry three further chunk types, each announced by a VP8X flag. ICCP holds an embedded ICC colour profile so colour-managed applications reproduce the intended colours; without it, WebP is assumed to be sRGB. EXIF holds an EXIF metadata block (camera settings, orientation, GPS), the same payload structure used in JPEG. XMP holds an XMP packet (XML-based metadata for editing and rights information). These chunks are purely informational; a decoder that does not care about them skips each one using its chunk size, exactly as with any RIFF chunk it does not recognise.

Frequently asked questions

Why did an image download as .webp instead of .jpg or .png?

The website served WebP to save bandwidth, since it is typically 25–35% smaller than JPEG and around 26% smaller than PNG at similar quality. “Save image as” gives you the original bytes the browser received, which are WebP. Convert it to JPG or PNG afterward if an app or upload form will not accept .webp.

How can I tell whether a WebP is lossy or lossless?

Read the FourCC of the first chunk after the WEBP tag at offset 8. VP8  (with a trailing space) is simple lossy, VP8L is simple lossless, and VP8X is an extended file whose real image data appears in a later VP8  or VP8L chunk. The VP8X flags byte then says whether alpha, animation or metadata are present.

Does converting WebP to JPG keep transparency?

No. JPEG has no alpha channel, so any transparent area becomes a solid background colour. If the WebP has transparency (its VP8X alpha flag is set, or it is a VP8L file), convert to PNG instead to preserve it.

References