PXPixelConvert
PixelConvert menu
← All guides

Reference guide · cited sources

Choosing a JPEG Quality Setting

The quality slider is the control people adjust most and understand least. It is not a percentage of the original retained, it is not comparable between tools, and the right value depends far more on what is in the picture than on any general recommendation.

By Prashantkumar Kishanrao Sundge · Published · Reviewed

What this guide establishes

  • The quality number scales how aggressively information is rounded away. It is an encoder instruction, not a proportion kept.
  • Quality 80 in one library is not quality 80 in another, and JPEG 80 is unrelated to WebP 80.
  • For photographs, roughly 75–85 is where most people stop noticing degradation while the file keeps shrinking.
  • Above about 95 you pay a great many bytes for differences almost nobody can see.
  • Content matters more than the setting. Sharp text and flat graphics degrade at values where photographs still look fine.

What the number actually controls

JPEG compresses by transforming small blocks of the image into frequency components and then dividing each component by a value from a table and rounding the result. Components that round to zero disappear, and zeros compress to almost nothing. That rounding is the entire lossy step.

The quality setting scales that table of divisors. A higher number means smaller divisors, less rounding, fewer components lost, and a larger file. A lower number means larger divisors, more components rounded away, and a smaller file.

So the number is a parameter controlling one step of an algorithm. It is not a measurement of how much of the image survives, and there is no sense in which quality 50 keeps half of anything. Treating it as a percentage leads people to pick values far lower than they intended.

It also explains why the loss cannot be undone. Once a value has been divided and rounded, the original is unrecoverable — many different inputs produce the same rounded output. No amount of re-encoding at a higher quality later restores anything; it simply stores the already-damaged pixels more faithfully in a larger file.

Why the numbers are not comparable

Different encoders implement the scaling differently, use different base tables, and make different decisions about colour subsampling and other parameters that travel alongside the quality setting. Two libraries can both offer quality 80 and produce visibly and measurably different files from identical input.

This means a quality value copied from an article, a forum post, or a colleague's workflow is a starting point rather than a specification. If a number matters — because it is written into a process or a client brief — it needs to be tied to the specific tool that produces it.

Across formats the comparison is meaningless rather than merely imprecise. WebP quality 80 and JPEG quality 80 are settings for entirely different algorithms. WebP at a given number generally produces a smaller file at comparable appearance, but the numbers are not measuring the same thing and converting one setting to the other is not possible.

The practical consequence: judge by looking at the output and at the file size, not by the number that produced it.

Values that work in practice

For photographs destined for a screen, the range from roughly 75 to 85 is where most people stop perceiving degradation at normal viewing size while the file continues to shrink meaningfully. This is the default territory for web images and email attachments, and going below it starts producing visible artifacts in smooth areas and around edges.

Around 90 to 95 is appropriate when the image will be examined closely, enlarged, or used as an intermediate in further work. Above 95 the file grows steeply while the visible difference becomes very hard to detect — you are spending bytes on detail the format is barely discarding anyway.

Below about 60, artifacts become apparent to ordinary viewers on ordinary photographs: blocking in skies and gradients, haloing around high-contrast edges, and a general loss of fine texture. There are situations where a hard byte ceiling forces this, and it is a compromise rather than a choice.

These are conventions rather than measured thresholds, and they assume photographic content viewed at a sensible size. State them as starting points and then look at the actual result.

Content matters more than the setting

The same quality value produces wildly different outcomes depending on what is in the picture, because JPEG's compression is tuned for smooth tonal variation and fails on sharp edges.

A portrait against a plain background tolerates aggressive compression well. A photograph of foliage, gravel, fabric texture, or a crowd holds up much less well, because the fine detail that makes it interesting is exactly what the encoder discards first — and it also compresses poorly, so the file stays large anyway.

Anything with sharp text degrades at settings where photographs still look perfect. A screenshot at quality 85 already shows haloing around letters. This is not a reason to raise the quality; it is a reason not to use JPEG. Our measured comparison found a sharp-text image at 33,657 bytes as optimized PNG against 49,875 bytes as JPEG quality 70 — larger and visibly worse.

Flat graphics, logos, diagrams, and line art all belong in a lossless format for the same reason. When you find yourself pushing a quality slider high to make text legible, the format is the problem.

Working to a byte ceiling

When a form imposes a maximum file size, the usual approach is to guess a quality, export, check the result, and repeat. People converge slowly and almost always overshoot downward, ending well under the limit with an image worse than it needed to be.

A bounded search does this properly: it tests quality values systematically and selects the highest one that still fits under the ceiling. The result uses as much of the available budget as the limit permits rather than leaving quality on the table.

If the highest permitted dimensions still cannot fit at any tested quality, the remaining lever is dimensions — and reducing them is usually the better trade. Removing pixels before encoding lets the encoder use a gentler setting on what remains, which generally looks better than crushing the quality of a full-resolution image. Our measured case study landed on exactly that: a 5 MB source met a 200 KB ceiling by halving the dimensions and using quality 62, rather than by compressing the full-size image into the ground.

When dimensions are fixed and quality alone cannot reach the ceiling, the request may simply be unsatisfiable for that image. Simplifying the composition genuinely helps, because a busy background is what makes a file incompressible.

Related settings worth knowing

Progressive encoding stores the image in several passes so it appears at low resolution first and sharpens as it loads, rather than painting top to bottom. It usually produces a slightly smaller file and a better perceived loading experience. A small number of older validators reject progressive JPEGs, which is worth trying as a fix when a form refuses a file for no visible reason.

Chroma subsampling stores colour information at lower resolution than brightness, exploiting the fact that human vision is less sensitive to fine colour detail. It saves a substantial fraction of the data on photographs and causes visible colour smearing on sharp coloured edges — another reason graphics and text do not belong in JPEG.

Optimised Huffman tables cost a little encoding time and produce a slightly smaller file with no quality change at all. There is no reason not to enable this when the tool offers it.

Metadata is worth stripping from published images: it adds bytes to every request and can carry location data you did not intend to publish.

A procedure rather than a number

Start by checking whether JPEG is the right format at all. Photographs yes; screenshots, diagrams, logos, and anything with text, no.

Then pick a starting value in the 75–85 range for screen use, export, and look at the result at the size it will actually be displayed. Not at 400% — every lossy image looks bad at high magnification, including ones that are entirely fine in use.

Check the places JPEG fails first: smooth gradients for blocking, high-contrast edges for haloing, and areas of fine repeated texture for mush. If those four look acceptable, the rest of the image will be.

Adjust once if needed and stop. The difference between adjacent quality values is small, and iterating repeatedly on a file you keep re-saving introduces generation loss that outweighs any gain. Better still, keep a lossless master and export a fresh copy each time rather than re-compressing the same JPG.

How this guide was written

This is a reference guide. It explains published specifications, platform rules, and format behavior, and every factual claim is attributed to the sources listed below. It does not report an in-house PixelConvert measurement, and no result here should be read as one.

Read how PixelConvert separates measured and reference guides →

Limitations

  • This guide explains what the quality parameter controls and cites the specification; it reports no in-house PixelConvert measurement. The byte figures it references come from the measured guides that produced them.
  • Quality ranges are widely used conventions for photographic content, not measured thresholds, and the right value depends on the image, the encoder, and the display size.
  • Encoder behavior varies between libraries and versions; a quality value is meaningful only in relation to the tool that produced it.

Frequently asked questions

What JPEG quality should I use?
For photographs on screen, roughly 75 to 85 is where most people stop noticing degradation while the file keeps shrinking. Use 90 to 95 when the image will be examined closely or edited further. Treat these as starting points and look at the result.
Does quality 80 mean 80% of the original is kept?
No. The number scales a table of divisors used to round away frequency information. It is an encoder instruction, not a proportion retained, which is why treating it as a percentage leads people to choose values far lower than they intended.
Is JPEG quality 80 the same as WebP quality 80?
No. They are settings for different algorithms and the numbers are not measuring the same thing. WebP at a given value generally produces a smaller file at comparable appearance, but the settings do not translate.
Why does my screenshot look bad even at high quality?
Because JPEG discards the high-frequency detail that letter edges are made of, so text acquires a halo at settings where photographs still look perfect. The fix is the format, not the slider — use PNG.
How do I hit an exact file size limit?
Use a bounded search that tests quality values and picks the highest one that fits, rather than guessing and overshooting downward. If quality alone cannot reach the ceiling and dimensions are free, reducing dimensions usually looks better than extreme compression.
Can I improve a low-quality JPG by re-saving it at quality 95?
No. The information was discarded by rounding at the original encode and is not recoverable. Re-saving at a higher quality stores the already-damaged pixels more faithfully in a larger file.

References