How WebP Keeps Transparency Exact in a Lossy Image

WebP is specified in RFC 9649, published by the IETF in 2024 after more than a decade as a Google document. The file is a RIFF container, the same chunk structure WAV audio uses: the bytes RIFF, a length, the bytes WEBP, then a sequence of chunks, each with a four-character name, a length and a payload.

Three layouts exist. A simple lossy file holds one VP8 chunk with the VP8 key frame. A simple lossless file holds one VP8L chunk. Anything more, whether transparency on a lossy image, animation, a color profile or metadata, uses the extended layout, which starts with a VP8X chunk whose flag bits announce what else is in the file. An alpha flag in VP8X, followed by an ALPH chunk and then the VP8 image data, is how a lossy WebP carries transparency.

VP8 was designed for video and has no idea what transparency is. It encodes brightness and color only. So the alpha channel travels beside it in the ALPH chunk, as a plane of one byte per pixel, and its first byte describes how that plane is stored.

The compression method is either none or WebP lossless. The libwebp encoder uses lossless by default, which means the alpha decodes to exactly the values it was given. A filtering method can predict each alpha value from its neighbour to the left, above, or a gradient of both, the same idea PNG's filters use, before the lossless coder sees it. And an optional preprocessing step, level reduction, can quantize the alpha values to fewer levels to save space, which is the one lossy option for alpha and is off unless an encoder chooses it.

The result is a file where the colors may be approximated but the shape of the transparency is exact. An anti-aliased edge stays at precisely the opacities the artist drew. That matters more than it sounds: errors in color are hard to see, but errors in alpha show up as jagged or haloed outlines against whatever the image sits on.

WebP also has a fully lossless mode, VP8L, built from scratch rather than borrowed from video. It runs a sequence of reversible transforms over the image: a predictor transform with fourteen prediction modes chosen per tile, a color transform that removes correlation between channels, a subtract-green step, and color indexing for images with few colors. It then encodes with LZ77 back-references, a small cache of recent colors, and Huffman codes. Google measured it at about 26 percent smaller than PNG on the same images.

The catch is in how web pages produce images. A page encodes through canvas.toBlob(callback, "image/webp", quality), and the HTML specification leaves it to each browser what that quality number means. Chromium-based browsers switch to lossless VP8L at exactly 1.0, a behaviour added to Chromium in 2016 to match how its JPEG encoder treats maximum quality. The specification does not require it, and below 1.0 every browser writes lossy color with the alpha plane stored losslessly alongside. That is the right result for photographs and most graphics. For pixel art and screenshots that must stay exact, keep the PNG, or use a desktop encoder such as libwebp's cwebp -lossless where the result does not depend on the browser.

For photographic cut-outs, such as products, people and objects on a removed background, 75 to 80 gives files far smaller than PNG with no visible difference. The color is what is compressed, and color noise in a photograph hides compression well.

Logos, icons, text and interface elements are different. They are made of sharp edges and flat color, which is exactly what lossy compression smooths, and VP8 always stores color at half resolution, so thin colored strokes lose definition first. Use 90 or higher for these and compare at full size, looking at the smallest text. If the WebP is not meaningfully smaller than the PNG at a quality that keeps the edges clean, the PNG was already efficient and is the better file to ship.