WebP is efficient to begin with, which changes what this page is for.
If your WebP came out of a modern export pipeline, it may have very little slack left — and re-encoding it at its existing quality will produce a file of almost exactly the same size. That is not a failure; it is the encoder correctly reproducing the same amount of detail.
To get smaller you have to go below whatever quality the source used. You usually cannot tell what that was, which is why the size readout matters more than the number on the slider.
Read the number, not the setting
Move the slider down, release it, read the result. Repeat until it fits.
There is no reliable formula from a quality setting to a file size, because the answer depends entirely on the image. A photograph of foliage and a photograph of a clear sky respond completely differently to the same value.
Every adjustment re-encodes from your original file rather than from the previous result, so you can move the slider as often as you like without compounding the damage.
If the destination is a web page and your audience is reasonably current, converting to AVIF will beat anything this page can do.
On the fixed test image used across this site, the same source came out at 247 KB as WebP and 104 KB as AVIF — a saving no WebP quality slider reaches without visible damage.
Compressing the WebP is the right call when the destination requires WebP specifically, or when you need broader support than AVIF offers.
Check the result at full size
Compression damage is invisible in a thumbnail and obvious at 100%.
Look at flat areas — skies, plain walls — where banding appears first, and at hard edges, where haloing shows. If either looks wrong, step back up. The damage is permanent.
Questions
- Can I compress a WebP without losing quality?
- Not meaningfully. This page produces lossy WebP, so smaller means less detail. What you can do is lose an amount nobody notices — around quality 82 most photographs are indistinguishable from the source at normal viewing sizes.
- Why did quality 82 not make my file any smaller?
- Because your file was probably already encoded at around that quality. Re-encoding at a setting a file already uses reproduces the same amount of detail, and therefore the same size. To get smaller you have to go below whatever the source used.
- Why did raising the quality make the file bigger?
- Because you asked the encoder to preserve more detail than the source contains, so it spends extra bits faithfully recording the original's own compression artefacts. Raising quality above a file's existing level always costs size and never improves the picture.
- Would converting to AVIF be better than compressing?
- Usually, if your audience is current. On our fixed test image, AVIF from the same source came out at 104 KB against WebP's 247 KB. Compressing the WebP only wins if you need to stay in WebP specifically.
- Does moving the slider repeatedly degrade the image?
- No. Every adjustment re-encodes from your original file rather than from the previous result, so there is no generational loss however many times you move it.
- Is transparency preserved?
- Yes. WebP carries a full alpha channel even in its lossy mode, which is one of the things that makes it more useful than JPG.
- Is my image uploaded?
- No. The decode and re-encode both run in this browser tab. The Uploaded readout beside the result measures the page's own outbound traffic, so a successful run reads 0 B.
- Is there a file size limit?
- None imposed. There is no server and no bandwidth cost, so your device's memory is the only ceiling.
- Will there be a watermark?
- No. Nothing is added to the image and no setting is held back behind a paid tier.
- What quality should I use for a website?
- 82 is a sound default. Below about 60 you will start to see softening in areas of flat colour. Above 90 you pay for file size that most visitors will never perceive.