Setup. We took a 1600×1600 iPhone-class photo (a 95.4 KB HEIC), decoded it once, and re-encoded the identical pixels at every quality setting from 10 to 100 in both JPG and WebP using the browser's own canvas encoders (Chromium 147). Same source pixels, same machine, twenty encodes. Bytes below are exact.
| Quality | JPG | WebP | WebP saving |
|---|---|---|---|
| 10 | 22.9 KB | 16.8 KB | −26% |
| 20 | 31.3 KB | 19.6 KB | −38% |
| 30 | 40.4 KB | 21.7 KB | −46% |
| 40 | 48.2 KB | 23.9 KB | −50% |
| 50 | 55.4 KB | 26.8 KB | −52% |
| 60 | 62.8 KB | 30.0 KB | −52% |
| 70 | 76.0 KB | 32.5 KB | −57% |
| 80 | 102.9 KB | 40.6 KB | −61% |
| 90 | 180.1 KB | 79.2 KB | −56% |
| 100 | 918.1 KB | 867.8 KB | −5% |
What the numbers say
- Quality 100 is a trap. Going from 90 to 100 multiplied the JPG by 5× (180 KB → 918 KB) and the WebP by 11× (79 KB → 868 KB) — for a difference no one can see. Both encoders essentially stop discarding anything at 100, so you pay near-lossless prices for a lossy format. If you want lossless, use PNG deliberately; never use "quality 100" as a superstition.
- At the same quality setting, WebP ran 26–61% smaller, with the biggest gap (−61%) at quality 80 — exactly the range most sites serve. This is why "convert your JPGs to WebP" keeps showing up in page-speed audits.
- The HEVC baseline puts both to shame. The 95.4 KB HEIC original lands between JPG-80 and JPG-90 in size while being visually the reference — a good reminder of why iPhones store HEIC and why a converted JPG is usually bigger than the HEIC it came from.
- The default on our converters (92) sits on the practical shoulder — beyond it, size climbs steeply for gains that need a magnifier.
Method and honest caveats
- Single sample: one 1600×1600 photographic image. Screenshots, flat graphics and text behave differently (WebP's edge usually widens). n=1 by design — this is a shape-of-the-curve study, not a survey.
- "Same quality setting" is not "same perceptual quality": the q-scale is encoder-specific, and we did not measure SSIM/butteraugli. The size curve, not cross-codec quality equivalence, is the claim.
- Encoders: Chromium 147's built-in canvas
toBlob(libjpeg-turbo / libwebp lineage) — the same code path our JPG → WebP and PNG → JPG converters use, so these numbers describe what this site actually produces. - Reproduce it: drop any photo into a converter here, move the quality slider, and read the size line — every row shows exact before → after bytes.