Compress WebP without losing quality

The short answer

A WebP file is not finished just because it is WebP. In our measurements a photo exported at quality 90 lost another 46 percent, a user interface screenshot lost 47 percent, and a painted illustration lost 36 percent, with an average pixel difference of about 1.5 out of 255 brightness levels. That is far below what an eye can pick up at normal size.

The lower the quality used at export, the less is left to take: at quality 80 we measured 19 to 35 percent, and at 75, which is the default of the standard command line encoder, only 7 to 18 percent. Lossless WebP is the opposite case, with 60 to 94 percent still on the table.

What we measured

We took three images that cover the usual jobs: a 1980 by 1440 photograph, a 1270 by 760 screenshot of a web page with small text, and a 1536 by 1024 painted illustration. Each was exported to WebP at quality 90, 85, 80 and 75, and once in lossless mode, which is what design tools and export presets actually produce. Then each of those files went through our compressor, and the result was compared with its input pixel by pixel.

Photo, exported at quality 90: 347,178 bytes became 187,918 bytes, a saving of 46 percent, with an average pixel difference of 1.54 and a largest single difference of 27 levels. At quality 85 the same photo went from 207,268 to 131,730 bytes, a saving of 36 percent. At quality 80, from 144,310 to 94,138 bytes, 35 percent. At quality 75, from 109,010 to 89,690 bytes, 18 percent.

Screenshot, exported at quality 90: 111,870 bytes became 59,308 bytes, a saving of 47 percent, average difference 1.45. At quality 80 the saving was 19 percent, and at 75 it was 7 percent. Illustration, exported at quality 90: 186,080 bytes became 119,092 bytes, 36 percent, with the saving falling to 19 percent at quality 80 and 7 percent at 75.

In every one of those runs, 99 percent of pixels changed by 15 brightness levels or less out of 255. The format never changed either: a WebP comes back as a WebP, at the same pixel dimensions.

Why an exported WebP still has room

Export presets are set once and applied to everything. A quality number that is genuinely needed for a portrait with smooth skin is wasteful on a screenshot of flat interface colours, and the exporter has no way to tell the difference. It also has no time to try several settings, because it is usually running inside a build step or a design tool that has to feel instant.

There is a second reason, and it is the bigger one on photographs: fine sensor noise. Grain that you cannot see at normal size is expensive to encode, because it is detail the encoder must spend bits on. Removing it is where most of the saving comes from, which is why a compressed photo can look slightly cleaner under heavy magnification than the file it came from.

Our approach is to try several encodings per image rather than trusting one setting, and then to check the winner against the input pixel by pixel. If the difference could become visible, the safer version is kept.

Lossless WebP is where the big wins are

Lossless WebP keeps every pixel exactly, and it pays for that in weight. The same photo exported losslessly weighed 2,713,020 bytes, and compressing it produced 174,470 bytes, which is 94 percent smaller. The illustration went from 1,131,102 to 124,014 bytes, 89 percent smaller. The screenshot went from 152,662 to 60,936 bytes, 60 percent smaller.

This is the one case that deserves a caveat. On the screenshot, which is full of small text, the largest single pixel difference was 75 levels out of 255, at the edge of a letter, even though 99 percent of pixels moved by 15 levels or less. For a page banner or a product photo that is irrelevant. If the file is a design source you will keep editing, or an archival screenshot where you want every pixel to be exact, keep the lossless copy and publish a compressed one.

Compress once, not three times

Every pass compares the result with whatever you fed in, not with the photo your camera took. Run the same file through repeatedly and the reference drifts with it. We measured that too: the photo lost 46 percent on the first pass, with an average difference of 1.54 from the export and a worst pixel of 27 levels. A second pass took it to 135,120 bytes, and the difference from the export grew to 2.12 average and 41 at worst. A third pass reached 115,846 bytes, 2.44 average and 51 at worst.

So the file does keep shrinking, and the damage does keep accumulating. Compress the best copy you have, once, and keep the source somewhere.

When a WebP will not get smaller

Some files are already at the floor: heavily compressed thumbnails, images that went through an aggressive build pipeline, or very small graphics where the file is mostly structure rather than picture. When nothing can beat the input without crossing the visual line, you get your original bytes back unchanged instead of a file that is the same size and slightly worse.

Animated WebP is a separate case. It is not compressed here, and an animated file is returned untouched.

How to do it

Drop your files on the WebP page linked below. Up to 20 files at a time, 25 MB each, no account and no watermark. Every file is processed in memory and never written to disk or logged, and the compressed copy goes straight back to your browser.

If this belongs in a build step instead, the same engine has a free API: one request sends the image and the response is the compressed file, with 100 images a day on the free tier.