Compress WebP

How to compress a WebP

1. Drop your .webp files into the box above, or click it to pick them.
2. Leave the output format on WebP. It is already set for you here — the dropdown is there in case you decide part-way through that you wanted a JPG or a PNG instead.
3. Set the quality. 75 is the default and a sensible landing point for photographs; go to 85–90 if the image contains text, a logo or hard edges, where the encoder’s shortcuts are easiest to spot.
4. Open Preview and drag the divider across the picture. The original is on the left, your new file on the right, and the quality slider re-encodes live so you can find the point where it starts to look wrong and then step back from it.

WebP is already compressed. So what is this doing?

Nothing clever, and it is worth being blunt about it. Your browser decodes the WebP back into plain pixels, the old encoding is discarded entirely, and libwebp encodes those pixels again from scratch at the quality you picked. There is no way to shave bytes off a lossy file without unpacking it first, so that is the only thing on offer.

Which means the useful question is not “how much smaller can this get” but how much slack was in the file to begin with. Re-encoding a photo that was already saved around this quality buys you a modest cut at best, and charges a second generation of lossy damage for it — the same compromise the encoder made the first time, made again on top of its own artefacts. Re-encoding a lossless WebP, or one somebody exported at quality 95 because the dialog defaulted there, is a different story entirely.

Those are not guesses. We took one 1600 × 900 photograph, saved it three ways with Google’s cwebp, and put each copy through this page at the default quality of 75. The lossless copy went from 1.3 MB to 103 KB. The quality-90 copy went from 228 KB to 96 KB. The quality-80 copy went from 130 KB to 105 KB — a real but unremarkable saving for a second pass of lossy encoding. A 512-pixel flat-colour graphic with a transparent background went the other way entirely: 2.3 KB in, 3.6 KB out. One photograph is not a benchmark, and yours will land somewhere else; the shape of the result is the point, and your own numbers appear on the row as soon as the file is done.

Lossy, lossless, and which one you get

WebP is two formats wearing one file extension. The lossless mode stores every pixel exactly, like PNG does, and is what most converters and design tools reach for when they are told to “export WebP” without being told anything else. The lossy mode throws away detail your eye is bad at noticing, like JPEG does, and is what makes WebP worth using on a website in the first place.

This tool always writes lossy WebP. The slider is the lossy quality parameter, passed straight through to libwebp with lossless mode switched off. That is deliberate: if you wanted lossless you would not be on a page about making the file smaller. If you do need pixel-exact output, switch the dropdown to PNG — that path runs OxiPNG instead and touches no pixels — and accept that a lossless photo is a heavy file whatever the container.

Working out which kind you were handed takes ten seconds. Divide the file size by the number of pixels: a lossy photograph tends to sit near a tenth of a byte per pixel, while a lossless one is commonly several times that. If you want certainty rather than a hint, look at bytes 13 to 16 of the file — VP8L means lossless, VP8  (with a trailing space) means lossy, and VP8X means the extended container used for transparency, animation or metadata, with the real image chunk sitting further in.

Why the WebP your CMS produced is heavier than it needs to be

Most oversized WebP files are not badly encoded. They are encoded faithfully, to a setting nobody chose on purpose:

• The export defaulted to lossless. A tool converting a PNG has no way to know you were happy to lose detail, so it does not, and hands you a file several times larger than a lossy one would be.
• The quality was set high “to be safe”. Between 90 and 100, libwebp spends a great many bytes on differences that survive no screen, no scroll and no phone.
• The source was full resolution. A 4000 pixel wide camera file converted straight to WebP is still a 4000 pixel wide image; the format changed, the workload did not.
• Metadata came along. Camera EXIF, an embedded colour profile and an XMP packet are all fair game to travel with the image, and on a small graphic they can outweigh the picture.

The first two are exactly what re-encoding fixes. The third is a resize job. The fourth happens here as a side effect — because the file is rebuilt from raw pixels, nothing from the old container survives into the new one.

When you should convert instead

Compression is the wrong tool if the format is the actual problem. If something refuses to open the file at all — an older Office or Photoshop, a print shop, an upload form with a fixed list — the fix is WebP to JPG for photographs, or WebP to PNG when there is a transparent background that has to survive.

Going the other way, if what you have is a heavy PNG or JPEG and you landed here hoping to lighten your pages, PNG to WebP and JPG to WebP do the conversion and the compression in one step — and a PNG turned into a lossy WebP is where the largest savings in this whole category live.