WebP to JPG: What a Second Lossy Pass Actually Costs

Baseline JPEG, standardised as ITU-T T.81 in 1992, does everything on a fixed grid. The image is converted from RGB into one brightness channel and two color channels, the color channels are usually halved in both directions, and every channel is cut into 8×8 blocks.

Each block goes through a discrete cosine transform, which re-describes its 64 pixels as 64 frequencies, from flat tone up to the finest checkerboard. Those coefficients are divided by a quantization table and rounded, which is where detail is actually thrown away, and the rounded values are packed with Huffman coding.

Two properties matter here. The blocks never move: they always start at pixel 0 and step by 8. And every block is coded on its own, with nothing smoothing the boundaries between them. At low quality, those boundaries are the visible blocks people associate with JPEG.

Lossy WebP is the intra-frame coder of the VP8 video format, specified in RFC 6386 and wrapped in the container RFC 9649 defines. It also works on brightness plus half-resolution color, but almost everything after that differs.

The image is cut into 16×16 macroblocks, and each one is first predicted from the already-decoded pixels above and to its left, using one of several directional modes. Only the difference between the prediction and the real pixels is transformed, with a 4×4 transform rather than 8×8, and quantized. The bits are then packed with a boolean arithmetic coder, which squeezes more out of the same data than Huffman can.

After decoding, an in-loop deblocking filter smooths the edges between blocks. That is why heavily compressed WebP looks soft and smeared where heavily compressed JPEG looks blocky. Google's comparison study measured lossy WebP at 25 to 34 percent smaller than JPEG at the same structural similarity score, and most of that gap comes from prediction and the better entropy coder.

Re-saving a JPEG at the same settings is close to harmless, because its coefficients already sit on the quantization grid and round to the same values. Converting WebP to JPEG gets none of that protection. The WebP's artefacts are smears and slightly displaced edges inside 16×16 regions. To the JPEG encoder they are simply detail, sitting at arbitrary positions relative to its 8×8 grid, and it spends bits describing them or rounds them into new errors.

The practical result is that the JPG carries both sets of artefacts: WebP's smoothing of fine texture, and JPEG's ringing and blocking on top. At high JPEG quality the second set is small enough to disappear. At low quality the two compound, and a picture that looked fine as WebP looks noticeably worse as JPG at a setting that would have been fine from the original.

Lossy WebP can carry an alpha channel, stored separately from the color and compressed losslessly. JPEG has nowhere to put it. Every pixel has to become fully opaque, which means compositing the image onto a background color before encoding.

The formula is the standard "over" operation: each output channel is alpha × color + (1 − alpha) × background. A fully transparent pixel becomes the background, an opaque one keeps its color, and an anti-aliased edge pixel at 40 percent becomes a blend. Choose a background that matches where the JPG will be shown. Skip the step, and a canvas encoder treats transparency as black, because a transparent canvas pixel is stored as zero in every channel.