Compress WebP

WebP is a more capable codec than JPEG. It predicts each block from its neighbours before compressing the difference, which JPEG cannot do at all, and the result is typically 25 to 35 per cent smaller at the same visual quality. Somebody arriving here has usually already taken that win.

What remains is the ordinary trade: lower the quality, lose some detail, save some bytes. Expect the numbers to feel less dramatic than compressing a JPEG, because the easy savings were collected when the file became a WebP.

Both formats offer a number from 1 to 100 and the numbers do not mean the same thing. WebP at 70 holds up about as well as JPEG at 80, so the reflex of "never go below 80" carries over as needlessly cautious and leaves savings on the table.

The reliable method is to look rather than to calculate. Compress, look at the result at the size it will actually be displayed, and adjust. The control sits under the result so that a second attempt costs one click.

For a website, the largest single saving is almost never the codec — it is not shipping a 3000-pixel image to a phone that will draw it 400 pixels wide. The resize control handles the simple version of that, and the proper version is a `srcset` with two or three widths, which the browser then picks from.

If you are optimising a page rather than one file, resizing first and compressing second is the right order. Compressing an oversized image produces a small file of a picture nobody needed at that size.

If the file was written in WebP’s lossless mode, re-encoding it lossily will shrink it substantially and re-encoding it losslessly will achieve almost nothing — the pixels are already stored as compactly as the format manages.

Nothing in the extension says which mode a file uses. A rough guide is size against dimensions: lossless WebP of a photograph lands in PNG territory, lossy WebP is a fraction of that. If compression achieves nothing, the file is very likely already lossy and near its floor.

WebP carries an alpha channel in both its lossy and lossless modes, which is a capability JPEG lacks entirely. Re-compressing a WebP keeps the transparency intact.

The alpha channel is stored losslessly even when the colour is not, so an image with a large soft-edged transparent region compresses less well than an opaque one of the same dimensions. That is the usual explanation when a cut-out product shot refuses to get as small as a photograph beside it.

An animated WebP is a sequence of frames, and re-compressing it means re-encoding every one. The saving is proportionally similar to a still image and the time taken is not — a three-second animation is dozens of frames.

Where an animation is genuinely large, resolution and frame rate are far more effective levers than quality. Halving the width quarters the pixel count in every frame at once, which no quality setting approaches.

A screenshot, a logo or a diagram is mostly areas of one colour, and a lossless WebP has already stored that about as tightly as it can be stored. Pushing the quality down on that kind of picture buys very little and starts to blur the edges of text, which is exactly where the eye is least forgiving.

A photograph is the opposite: it is full of the fine variation lossy compression was built to discard, and the same setting that ruins a screenshot is invisible on a landscape. If the file you are compressing has text in it, expect a smaller saving and check the result at full size before accepting it.

A WebP that was made from a JPEG has already been through one lossy pass, and compressing it again applies a second encoder to what the first one left behind. The artefacts do not average out; they accumulate, and they accumulate fastest in the areas that were already worst.

Where the original is still available, going back to it and encoding once is both smaller and better than two passes. Where it is not, a conservative setting on the second pass costs less than it looks like it should — most of the easy savings were taken by the first encoder anyway.