JPG Quality Settings Explained: What 75, 85, 95 and 100 Change

What does the JPG quality number mean?

The JPG quality number is an instruction to the encoder about how coarsely to round the image data. It is not a percentage of anything. A file saved at 90 does not hold 90% of the original, and a file saved at 50 is not half as good as one saved at 100.

A JPG encoder cuts the picture into small blocks and describes each block as a mix of patterns, from broad gradients down to fine detail. Each of those values is then divided by a number from a table and rounded. Big divisors round away more detail and leave a smaller file. That table is called the quantization table, and the quality setting scales it. In the words of the reference encoder’s documentation, the switch exists to “scale quantization tables to adjust image quality”.[1]

The conversion from the number you type to that scale is one small function in libjpeg-turbo, the JPEG library that Chrome and Firefox both use.[3] The standard table is used as it is at quality 50. Above 50, the table is scaled to 200 - 2 x quality percent. Below 50, to 5000 / quality percent.[2]

Read down the right-hand column and the shape of the scale appears. From 50 to 75 the rounding gets twice as fine. From 90 to 95 it gets twice as fine again, in five steps instead of twenty-five. From 95 to 99 it gets five times finer. The top of the scale is where the encoder is asked to keep detail that is smaller and smaller, and that detail is expensive to store.

Our own extension gets this wrong in one place. Its settings page shows the value as “95%”. The percent sign is shorthand for “95 on a scale of 100”, and it suggests exactly the reading this section argues against.

How much file size does each quality step cost?

On the photograph we measured, the file grows slowly up to about 85, more than doubles between 85 and 95, and quadruples between 95 and 100.

The test, run on 11 October 2026 in Chromium 151 on an Apple M3 Pro: a 1600 x 1067 photograph of a stack of printed photos, scaled down from a 5235 x 3491 camera original and held as a lossless PNG. The page drew it to a canvas and saved it as JPG at each quality through the browser’s own encoder. PSNR is a standard fidelity measure, in decibels, computed here over every red, green and blue value against the PNG. Higher means closer to the source, and it is a crude instrument: it counts numerical error and knows nothing about what an eye notices.

Compare two moves of about the same fidelity gain. Going from 60 to 85 adds 73 KB and 1.9 dB. Going from 85 to 95 adds 196 KB and 1.8 dB. The second move buys slightly less and costs nearly three times as much. Going from 95 to 100 adds another megabyte.

That matches what the encoder’s own documentation says about the top of the range: a value above about 95 “will increase the size of the compressed file dramatically”, and the gain is measurable with metrics such as PSNR but “rarely perceivable by human vision”.[1]

Your numbers will differ. This photograph has a soft, out-of-focus background, which compresses well. A picture full of sharp texture, such as foliage or fabric, produces larger files at every setting. The shape of the curve should hold, because it comes from the scaling table above.

Is quality 100 lossless?

No. Quality 100 is the least lossy setting a JPG has, and it still changes the picture. At 100 every divisor in the table is 1, which removes the rounding loss from that one step, “but there is still information loss in subsampling, as well as roundoff error”.[1]

Our quality 100 file confirms it. It was 1.31 MB and its pixels were not the source’s pixels: individual colour values were off by up to 4 levels out of 255. That error is far too small to see. It is also not zero, so the file is not a lossless copy.

Chrome and Edge do one more thing at exactly 100. Their canvas encoder stores colour at half resolution at every quality below 100 and at full resolution only at 100, while Firefox makes that switch at 90, and no standard says where the line belongs.[5] That switch is a large part of why the file jumps between 99 and 100, and why a converted image can come out bigger than the original walks through it with its own numbers.

If you need the exact pixels back, JPG is the wrong container at any setting. PNG is lossless by design, and it is the right choice for a picture you plan to edit again.

Does saving a JPG again make it worse?

Less than its reputation says, as long as nothing else changes. We took the quality 85 file and saved it again at 85, twenty times in a row, each save starting from the previous file.

After twenty generations the quality 85 file had lost a tenth of a decibel. The quality 95 chain lost more, 0.6 dB, and most of that in the first ten saves. Neither is the visible decay people expect. The reason is that the second save divides by the same table as the first. Values that were already rounded to multiples of those divisors mostly land on the same multiples again, so there is little left to lose.

The damage people remember comes from saves where something did change:

• A different quality. A new table means every value is rounded afresh.
• A crop or a resize. The 8 x 8 blocks no longer line up with the old ones, so the encoder starts from scratch on an image that already carries the first save’s errors.
• A different program. Two apps rarely share a table, even at the same number.
• An edit. Brightness, a filter, text on top: all of them change the pixels before the next rounding.

So the working rule is narrower than “never re-save a JPG”. Keep the editing master in a lossless format and export a JPG once at the end. A plain save of an untouched JPG at its own quality is close to harmless. Our extension avoids even that: a JPG saved as JPG with no resize is written straight through from the original bytes with only its metadata removed, and no second encode.

Is the WebP quality number the same scale?

No. WebP uses a different compression method, and its 0 to 100 is a separate scale that happens to share the range. The same photograph, the same browser, both formats:

At the same number the WebP is smaller and a little further from the source. Matched on fidelity instead, WebP at 90 lands next to JPG at 85 and is about a fifth smaller. The last row breaks the pattern. In this run, WebP at 100 came out pixel-for-pixel identical to the PNG, a lossless file larger than any of the lossy ones.

This is why a converter with separate sliders per format is doing something useful, and why one number applied to both is a compromise. In our extension the defaults are 95 for JPG and 90 for WebP, and each has its own slider under Quality Settings.

Why does the same number give a different file in another app?

Because the number has no definition outside the encoder that reads it. The web standard that browsers follow describes it only as “the desired quality level for the resulting image”, a number between 0.0 and 1.0, with nothing about what a given value must produce.[4] A web page that does not pass a value at all gets whatever default that browser picked.[6]

Desktop software has more room still. An app can ship its own tables, map its slider onto them however it likes, and make its own choice about colour resolution. A “quality 10” in one photo editor’s 0 to 12 scale has no fixed relation to 85 anywhere else. Even two tools with a 0 to 100 scale disagree: in a batch test for bulk converting images without uploading, macOS sips and ImageMagick were both asked for 85 and produced files 1.7 times apart.

The practical consequence: a quality number is a setting to learn per tool. When a file has a size limit to meet, save one image, look at the result, and adjust.

Which quality setting should you use?

The encoder’s authors put the useful range for photographs between 50 and 95, and suggest starting lower and moving up “5 or 10 counts at a time” until the picture looks right.[1] That advice has aged well. A high default makes sense for a converter that cannot know what you are saving or why, and it is worth lowering once you do know.

The quality number is one of three things that decide a JPG’s size. The other two are the pixel dimensions and how much fine detail the picture contains, and the first of those is often the bigger lever: half the width and height leaves a quarter of the pixels. If the reason you are here is a WebP that needed to become a JPG, saving a WebP as JPG covers the steps and the WebP problem, end to end covers the format.