The quality ladder: what each step actually costs

Measured 2026-07-23 · Chrome 148 on macOS; canvas encoders as shipped. Dataset B (separate from the format study): two deterministic 1600×1000 images — a dense high-frequency texture and a page of small serif paragraph text. Sweep: quality 50, 60, 70, 80, 90, 95, 100.

Question: As you push the quality slider from 50 to 100, how fast does the file grow for JPEG and for WebP — and is the top of the slider ever worth it?

Findings

  • WebP was smaller than JPEG at every step of the ladder on both images — by 57% at quality 50 on the texture image, and by roughly 30–40% throughout on the text page.
  • JPEG quality 100 is a trap. On the texture image it produced 2.40 MB against 943 KB at quality 95 — 2.5x the bytes for the last sliver of a lossy encode. The curve is gentle up to 90 and then turns sharply.
  • WebP quality 100 does the opposite: it got dramatically SMALLER, not larger — 68 KB against 304 KB at quality 95 on the texture image, and 53 KB against 393 KB on the text page.
  • We verified why rather than guessing: at exactly quality 1.0 this encoder switches WebP into LOSSLESS mode. Decoding the quality-100 output and comparing it against the source gave a maximum per-channel difference of 0 — pixel-identical — while quality 95 and even 99 differed by up to 96 levels. On structured content, lossless WebP beats a high-quality lossy encode on size as well as fidelity.
  • Practical consequence for our tools: dragging the quality slider to 100 on a WebP conversion is not "maximum lossy", it is a different, lossless codec mode — often both perfect and smaller. Dragging a JPEG conversion to 100 just wastes bytes.

The data

ImageFormatQualityBytes
photo-detailjpeg50316,293
photo-detailwebp50136,632
photo-detailjpeg60357,510
photo-detailwebp60149,314
photo-detailjpeg70419,089
photo-detailwebp70164,700
photo-detailjpeg80513,746
photo-detailwebp80196,758
photo-detailjpeg90714,995
photo-detailwebp90262,414
photo-detailjpeg95943,252
photo-detailwebp95304,044
photo-detailjpeg1002,403,299
photo-detailwebp10067,860
text-densejpeg50305,432
text-densewebp50207,490
text-densejpeg60342,183
text-densewebp60220,168
text-densejpeg70388,860
text-densewebp70232,670
text-densejpeg80451,592
text-densewebp80266,366
text-densejpeg90558,535
text-densewebp90332,522
text-densejpeg95664,960
text-densewebp95392,918
text-densejpeg100839,807
text-densewebp10052,596

⬇ Download raw data (CSV) ⬇ Download report (JSON)

Method

  1. Generate dataset B deterministically — a different, larger dataset from the format-comparison study, chosen for the two hardest compression cases (high-frequency texture and dense small text).
  2. Encode each image to JPEG and WebP at each quality step and record exact bytes.
  3. For the quality-100 result, verify losslessness directly: decode the output, compare it pixel-by-pixel against the source, and record the maximum per-channel difference.
  4. Download /labs/run-image-labs.js and paste its contents into the DevTools console.

Limitations

  • Synthetic sources chosen as worst cases; ordinary photos produce gentler curves.
  • Chrome 148 only — the quality-100 behaviour below is this encoder's policy, not a property of the WebP format itself, and other browsers may differ.
  • Byte size plus an exact losslessness check; no perceptual metric is claimed for the intermediate steps.

Takeaway

For JPEG, stop at 90 — beyond that you pay a great deal for nothing anyone can see. For WebP, either sit in the 70–85 range for real savings, or go all the way to 100 for a pixel-perfect lossless file that, on flat or structured images, can be smaller than the lossy versions. The middle of the WebP slider is the only place the usual size/quality trade-off applies.

Advertisements

← All Labs reports · standards in the testing methodology