Why WebP can be lossy or lossless

Two images can both end in .webp while making opposite promises.

One may return pixels that only look like the original. The other may return every value exactly. This is why “save it as WebP” tells us less than it appears to.

WebP is a container for two different codec families: a lossy path based on a VP8 intra-frame, and a separate lossless format called VP8L.

The microscope asks the browser to encode WebP, then reads the returned file header. That detail matters because the browser API accepts a desired quality value but provides no switch that says “use lossless WebP.” A quality value of 1 is still only a high lossy-quality request unless the returned bitstream says otherwise.

The file tells the decoder which WebP it contains

Near the beginning of a WebP file, a four-character code identifies what follows. VP8 marks the simple lossy stream. VP8L marks lossless data. VP8X introduces an extended container that can combine image data with features such as alpha, animation, color profiles, and metadata.

The WebP container specification defines that structure, while RFC 9649 specifies the two image formats.

The extension gets the file to a WebP decoder. The internal code tells that decoder which set of rules to use.

Those rules diverge at one decisive question: may the encoder throw precision away?

Lossy WebP first tries to guess the block

JPEG transforms a small block of image samples and then quantizes the resulting frequencies. Lossy WebP adds a prediction step before the transform.

When the decoder reaches a block, it has already reconstructed pixels above and to the left. Those neighbors often reveal the local direction of an edge or a smooth color transition. The encoder chooses a prediction that both sides can reproduce, then stores the difference between that guess and the actual block.

This difference is the residual. A good prediction leaves a residual with smaller, simpler values. VP8 transforms that residual and quantizes the result. Quantization rounds distinct values into the same stored representation, so exact reconstruction is no longer possible.

The prediction must use already reconstructed neighbors, not the unavailable originals. Otherwise, the encoder and decoder would make slightly different guesses and the error would spread across later blocks. RFC 6386 describes this intra-frame decoding process.

Lossy WebP therefore reaches compression through a clear causal chain: predictable neighbors produce a small residual; a small residual produces compact transform coefficients; quantization removes precision; the remaining symbols become cheaper to code.

Lossless WebP keeps the prediction but removes the irreversible step

VP8L also predicts pixels from their surroundings. It can additionally transform color relationships, subtract the green channel from red and blue, or replace recurring colors with palette indices.

These operations may rearrange the data dramatically, but each one is reversible. The encoder then looks for repeated sequences, recent colors, and common symbols. It can replace a repeated sequence with a backward reference, refer to a small color cache, and assign shorter codes to frequent values.

The decoder reverses those instructions and restores the same 8-bit color values. No quantization step sits in the middle.

This makes the difference between the two WebP paths much less mysterious. Both try to expose prediction and repetition. Lossy VP8 gains more compression by rounding the prediction error. VP8L must keep enough information to reconstruct that error exactly.

Why “WebP is smaller” is an incomplete comparison

The extension alone does not determine file size. An encoder still chooses how hard to search for predictions, transforms, repeated sequences, and entropy codes. The image itself determines which choices pay off.

Even a comparison between lossy WebP and JPEG needs a matching rule. Are the images compared at the same numeric error, the same perceptual score, or a quality setting that happens to share a label? Google’s WebP compression study reports results for specific encoders, datasets, and a Structural Similarity Index Measure (SSIM) matching method. It does not create a permanent exchange rate between .jpg and .webp.

The accurate unit of comparison is the whole experiment: format, encoder, settings, source images, and quality criterion.

The hidden bits reveal which promise we received

A payload stored in exact red-green-blue (RGB) bits survives only if those samples return unchanged.

Lossy VP8 cannot promise that. Its prediction may be excellent and the image may look clean, but quantization changes the reconstructed values. The hidden payload can fail for the same reason it fails in JPEG.

VP8L can preserve it because its transforms are reversible. A later resize, crop, color conversion, or lossy re-encode can still destroy it, but that damage belongs to the surrounding pipeline rather than to lossless decoding itself.

This gives us a practical rule. When exact values matter, do not reason from the extension or from a quality slider. Inspect the bitstream and identify the invariant of the codec inside it.

Both files are WebP. Only one of them promises the same pixels back.