What JPEG Quality Should I Use?

JPEG quality 80 is the right default for photographs, and it is roughly the wrong question for everything else. That is the short version. The longer version is that I got tired of every guide quoting different file sizes for the same advice, so I measured it.

Nine pages ranking for this question all recommend a JPEG quality somewhere between 75 and 85, and all of them quote numbers. One puts a 12-megapixel photo at 1.2 MB for quality 90. Another puts the same jump at 6 MB. Neither says which image it used, which makes both figures impossible to check or compare.

Where the savings actually are

I generated a 1200×800 test image with smooth gradients and per-pixel noise, which is what makes a real photograph expensive to store, and encoded it at every quality from 100 down to 10 using Chrome’s own encoder. Alongside each file size I measured root-mean-square error against the original. That is a plain pixel difference, not a perceptual score, and it is useful for one thing: showing where a curve turns.

The shape is the finding. Going from quality 100 to quality 80 takes the file from 711 KB to 238 KB, a two-thirds saving, while error climbs only from 0.66 to 6.81. Going from 80 all the way down to 30 saves just 184 KB more and pushes error to 10.91.

So the first two thirds of the savings are close to free and everything after that is expensive. Quality 80 sits almost exactly at the elbow, which is presumably how it became the folk advice in the first place. The folk advice is right. It is just never shown why.

The advice falls apart on screenshots

Here is what the guides miss. Every one of them tests a photograph and then gives you a number as though it applied to everything you might compress. It does not.

I ran the same sweep on a generated screenshot: flat panels, a heading, a table of rows. At quality 100 it came to 119 KB. At quality 95 it came to 57.6 KB. Over half the file disappeared across five quality points, and the measured error was still only 0.78. There is no elbow at 80 here, because the whole curve is somewhere else.

Push further and the picture changes again. A flat graphic of four solid rectangles came to 16.5 KB as JPEG at full quality and 21.5 KB as a lossless PNG. As WebP it came to 2.9 KB. That is seven times smaller than the PNG, for an image where JPEG has no business being used at all because it puts ringing artefacts around every hard edge.

WebP is smaller at the same visible error

Comparing formats by quality number is meaningless, because the numbers are not the same scale. Comparing them at equal measured error is not.

On the test photograph, JPEG at quality 90 produced 364 KB at an error of 3.71. WebP reached a near-identical 3.89 at 261 KB. Same picture, same measured damage, roughly 28% fewer bytes. If whatever you are uploading to accepts WebP, that saving is free and you should take it.

The reason to still reach for JPEG is compatibility, not quality. Every upload form, every email client and every ancient CMS accepts a JPEG. WebP support is now near-universal in browsers, but the form you are filling in is not a browser.

Re-saving a JPEG does not ruin it. Editing it does.

This is the one that surprised me, and it contradicts most of what is written about JPEG.

The received wisdom is the photocopier metaphor: every time you save a JPEG it degrades, so after five or six saves the damage is visible. I tested it by re-encoding the same photograph at quality 80, twenty times in a row, measuring against the original each time.

Error after the first save: 6.81. Error after the twentieth: 6.83. Effectively nothing.

The reason is that re-encoding at the same quality with the same encoder is very nearly a no-op. The first save already snapped every block onto that quality level’s quantisation grid. Doing it again asks the encoder to round numbers that are already round.

Change something, though, and it compounds immediately. Resizing the image by one percent between each of ten saves took the error from 6.81 to 12.67, and shrank the file from 238 KB to 127 KB as real detail was destroyed. Resampling moves every pixel off the 8×8 block boundaries it was quantised against, so the next save has genuinely new errors to introduce.

Which makes the practical rule more useful than the metaphor. Saving is cheap. Editing is what costs you. Ten rounds of open-and-save will not hurt a JPEG. One crop, one resize or one rotation between saves will. Keep the original if you expect to edit again, and if you are only re-exporting an untouched file, stop worrying about it.

Two limits on that finding, stated because they are real. This was Chrome’s encoder throughout; saving through two different programs means two different quantisation tables, which breaks the idempotence. And error against the original is not the same as what an eye notices.

What to actually do

• Photographs: JPEG quality 80. It is the elbow of the curve, and 82 or 78 will not change your life.
• Screenshots and interface captures: WebP, or PNG. JPEG puts visible ringing around text. If it has to be JPEG, do not go below 90.
• Flat graphics and logos: WebP. The measured gap over PNG was seven times on the test image, and PNG if you need guaranteed compatibility or transparency.
• Stop counting saves. Count edits.
• Do not trust a quality number across formats. WebP 80 and JPEG 80 are not the same amount of damage. Compare output, not settings.

If you want the number for your own image rather than my test set, the Image Compressor runs the same search and reports the quality it lands on, which is the part most tools leave out. It runs in your browser, so nothing is uploaded.