JPEG Quality 50–90: What 20 Real Images Actually Told Us

Search for "best JPEG quality" and you'll find the same advice everywhere: "60–80 is a good range", "never go below 50", "quality 90 looks identical to 100". What you won't find is data — file sizes and fidelity numbers measured on real images, with the encoder you'd actually be using.

This study asks three concrete questions:

• How much smaller does a file actually get at each quality step from 50 to 90?
• How much fidelity is lost at each step, measured rather than eyeballed?
• Does the answer change depending on what kind of image it is?

Test set — 20 images, four kinds of content:

The photographs are real-world photos (landscape, people, textured scenes) at 1600×1200. The screenshots are genuine captures of this website's pages. The documents are dense-text pages representative of scanned or exported documents. The illustrations are flat-color vector-style art.

Encoder: every image was decoded and re-encoded through an HTML5 canvas in Chromium 151 (Windows 10), calling canvas.toBlob('image/jpeg', q) at quality 0.50, 0.60, 0.70, 0.80 and 0.90. This is the exact code path our Image Compression tool uses — the browser's built-in libjpeg-based encoder, the one you get when you compress images in any modern web app. No command-line tool, no different codec family.

Fidelity metric: SSIM (structural similarity, grayscale, 11×11 Gaussian window, σ = 1.5) between the lossless decoded original and the re-encoded result. SSIM ranges from 0 to 1; values above ~0.98 are usually visually indistinguishable, and below ~0.95 differences start to be noticeable.

File size: actual encoded bytes, reported relative to the original file's size (1.00× = no change).

Environment: Chromium 151.0.7922.34, Windows 10 Pro, 2026-09-29. The main run encodes 20 images × 5 qualities (100 encodes); a supplementary run re-encodes the 10 photographs from a lossless PNG source × 6 qualities (60 more). The complete per-image results are published as raw data: r1-results.json.

Averages across the 10 photographs (all 1600×1200, original files already JPEG-compressed):

The most practical finding of this study: at quality 70, the re-encoded photo was on average 0.99× the original size — essentially no savings at all. The sources in our test set were themselves JPEG-compressed photos, and re-compressing an already-compressed JPEG at a similar quality level is close to a no-op. Real savings only begin once you go below the source's effective quality:

• Q60: 11% smaller, SSIM 0.98 — still visually clean.
• Q50: 23% smaller, SSIM 0.96 — visible only if you look for it (see the comparison below).

Meanwhile Q90 grew files by 25% with no meaningful fidelity gain over Q80. Re-encoding photos at high quality doesn't preserve quality — it just costs storage.

What if the source is lossless? The numbers above describe the common real-world case of re-compressing an already-JPEG photo. So we ran a supplementary pass: we decoded each of the 10 photos to a lossless PNG (average 2,434 KB — this is what an uncompressed photo of this size actually weighs) and re-encoded that through the same canvas encoder:

The perspective shift is dramatic: from a lossless source, every quality setting is a massive win — even Q90 removes 90% of the weight. The slider now only trades a 1.6× size difference (Q50 vs Q90) against fidelity, which is why Q75–80 is a comfortable default here: the fidelity gain over Q60 is real (0.996 vs 0.983), and the extra cost is just 2% of the lossless size.

Here is a center crop of one test photo. Left: lossless reference. Right: quality 50:

Averages across the 4 UI screenshots (1600×1000, PNG sources):

Converting a PNG screenshot to JPEG at Q50 halves its size, and SSIM stays high. But the artifacts JPEG introduces on flat UI surfaces and text edges — ringing along borders, slightly dirty whites — are exactly the kind of damage screenshots are sensitive to. If you need a screenshot smaller than PNG, a lossless or near-lossless format (WebP lossless, or lossy WebP at high quality) usually beats JPEG for this content type. That comparison is exactly what our planned Study 02 (WebP vs JPEG) will measure.

Text documents (1240×1754, PNG sources) and flat illustrations (1600×1200, PNG sources):

For both content types, JPEG was the wrong tool at every quality level:

• Text documents got bigger, not smaller. PNG's lossless run-length-style compression is extremely efficient on crisp text; JPEG's 8×8 DCT blocks smear the sharp glyph edges and cost more bytes doing it. At Q90 the JPEG was nearly double the PNG. Converting scanned text pages to JPEG to "save space" does the opposite.
• Flat illustrations inflated 2.3–4.4×. Same mechanism: PNG stores large flat regions almost for free, while JPEG has to encode every 8×8 block.

The anomaly worth knowing about: notice the illustrations' SSIM at Q70 — 0.9317, worse than Q50's 0.9786, while the file is bigger. This inversion reproduced consistently on all three illustrations. The likely mechanism is the interaction between JPEG's 8×8 block quantization and chroma subsampling on large flat saturated regions: at mid-range qualities, residual DCT coefficients are kept just precisely enough to form visible block boundaries on flat color, while at Q50 heavier quantization smooths those regions flat instead. In other words, on flat art there is a quality band (in our test, around Q70) that is simultaneously bigger and more artifacted than Q50. We haven't seen this covered in mainstream compression guides — it's exactly the kind of thing generic advice misses.

Here is the same effect on a text document. Left: lossless reference. Right: Q50 — note the ringing around glyphs, and remember this file is 6% larger than the PNG it came from:

An honest study states what it doesn't cover:

• 20 images is enough to expose the patterns above, but per-image variation is real — a noisy high-ISO photo behaves differently from a clean studio shot. Our per-image data (published above) spans SSIM 0.92–0.98 at Q50.
• We measured SSIM, not human judgment. SSIM correlates well with perceived structure loss, but a formal viewer study would be stronger evidence.
• The photo sources were themselves JPEG-compressed (as most real photos are). Findings about "already-compressed" photos specifically reflect that common real-world case — the raw-photo case is called out separately in the conclusions.

Next studies: Study 02 — WebP vs JPEG will measure whether the format switch beats the quality slider, and Study 04 will look at what EXIF metadata survives this whole process.