Which JPEG or WebP quality setting should you actually use?

Every compressor gives you a quality slider from 1 to 100 and no guidance about where to put it. We measured the file size at every step of that slider, on seven different images, to find out where the extra quality actually stops buying you anything.

Quality 100 is a trap

The most striking result is at the top of the range. Going from quality 90 to quality 100 on our landscape photograph inflated the file by 240% — from 231 KB to 786 KB — for a change essentially nobody can see.

What is happening is that JPEG’s quality number controls how aggressively it rounds off detail within each block. At the top of the scale it is preserving differences far below the threshold of human vision — and encoding noise from the camera sensor along with them. You get a much bigger file that encodes grain more faithfully.

Where the curve flattens

Read the table from the bottom up and a shape appears. Between quality 10 and 50 the file grows steadily, and so does visible quality — low settings produce obvious blocking. Between 50 and 80 the growth continues but the visible improvement narrows sharply. Above 90 the file grows steeply while the image barely changes.

On the landscape photo, dropping from quality 80 to 50 saved 55% of the file size. Going the other way, from 70 to 80 cost 62% more bytes. That asymmetry is the useful part: the cheapest quality is in the middle of the range, and the most expensive is at the very top.

Busy images cost more at every setting

The same slider position produces wildly different files depending on content. At quality 80 our saturated close-up came out at 422 KB while the landscape was 186 KB, despite similar dimensions.

This is why “save everything at 80” is a rule of thumb rather than a rule. If you have a hard budget — say, every image on a page under 150 KB — the quality setting that hits it depends on the photograph. Our compressor shows the resulting size as you drag, which is a faster way to hit a budget than guessing.

WebP behaves the same way, at lower absolute cost

WebP’s quality scale follows the same curve — steep at the top, flat in the upper-middle — but starts from a smaller baseline. The same landscape at WebP quality 80 was 84 KB against JPEG’s 186 KB.

One practical note: WebP quality numbers are not directly comparable to JPEG quality numbers. WebP 80 and JPEG 80 are different amounts of compression, not the same amount in a different format. Judge by the resulting file size and how the image looks, not by matching the numbers.

What we actually recommend

75–85 for photographs on the web. This is the flat part of the curve — small files, and artefacts that are genuinely hard to spot at normal viewing size. If you save one number from this page, save 80.

60–70 when size matters more than fidelity. Thumbnails, background images, anything displayed small. Artefacts that are obvious at full size disappear when the image is shown at 300px wide.

90 or above only when something downstream will re-encode. If the image is going to be edited and saved again, or handed to a platform that will compress it a second time, starting higher gives the next encoder more to work with. Each JPEG save compounds the previous one’s damage.

Never 100. On our test images it cost between 40% and 240% more than quality 90 for no useful gain. If quality 90 is not enough, you want a lossless format.

A note on repeated saving

Quality settings apply each time a lossy file is encoded. Opening a JPEG, cropping it and saving at 80 does not preserve the original 80 — it applies a second round of loss on top of the first. Do this a dozen times and the degradation is obvious.

This is why our editor keeps your edits as a list of steps and re-runs them from the original file rather than re-encoding after each one. Ten edits still means one encode at the end.

How we measured this

Each of seven images was encoded at every quality step from 10 to 100 in headless Chromium, through the same canvas.toBlob(type, quality) call the site’s tools use, and the resulting byte counts recorded. The tables on this page render directly from that output. Full method and image sources are listed in the format comparison.