The short answer
For photographs, quality 75 to 85. On our corpus, quality 75 produces files around 1.1 bits per pixel; quality 95 produces 3.3 times as much file for a quality improvement you need a measuring instrument to state. Below about 60 the trade reverses: the file barely shrinks while the damage becomes visible. For screenshots, diagrams and anything with hard edges and text, the honest answer is a different format, and the numbers below show why.
Every figure on this page was measured, not quoted: the same encoder builds this site’s image compressor runs in your browser, over a fixed corpus, scored with SSIM against the originals.
What the quality dial actually does
Two things stand out. The cost curve bends hard after 85: on photographs, each step of the dial above there buys less and costs more, and the last ten points to 95 nearly double the file. And the four content categories barely share a chart. Photographs occupy the whole quality range; interface screenshots, text and graphics sit pinned near the top of the SSIM axis at every setting, because most of their pixels are flat colour that JPEG reproduces easily. Their problem is different, and it is the one SSIM under-reports: ringing around hard edges and smudged text, which is exactly what JPEG’s block transform does to sharp boundaries. A metric averaged over a screenshot full of flat regions barely notices a halo around each letter; your eyes do. That is why the right move for screenshots is not a higher JPEG quality but PNG, which keeps edges exact by construction.
The knee, in numbers
| Quality | Bits per pixel | Size, against quality 75 | SSIM |
|---|---|---|---|
| 50 | 0.66 | 62% | 0.8884 |
| 60 | 0.77 | 72% | 0.9045 |
| 75 | 1.07 | 100% | 0.9315 |
| 85 | 1.63 | 153% | 0.9540 |
| 95 | 3.56 | 333% | 0.9817 |
Reading down the photograph table: dropping from 75 to 50 saves about 38% of the bytes and costs 0.043 of SSIM, the largest quality drop in the table. Climbing from 75 to 85 costs half as much again in bytes for a 0.023 gain. Climbing from 85 to 95 more than doubles the file again for 0.028. The steps look symmetrical on the dial and are nothing like it in the files.
Encode time
Time scales with the setting as well as with pixels: on our machine, mozjpeg spent about 88 ms per megapixel at quality 10, 184 at 75 and 482 at 95, single-threaded. This is why a target-size search over a 40-megapixel photo takes real seconds in the compressor: each probe is a full encode of every pixel.
PNG has levels, not qualities
PNG is lossless, so its dial trades time, not fidelity. oxipng’s levels repack the same exact pixels with increasing effort:
| oxipng level | Mean saving | Seconds per megapixel |
|---|---|---|
| 0 | 2.8% | 0.2 |
| 1 | 5.4% | 0.4 |
| 2 (this site’s default) | 8.1% | 1.0 |
| 3 | 8.2% | 3.1 |
| 4 | 8.5% | 3.7 |
| 5 | 8.9% | 6.0 |
| 6 | 8.9% | 7.2 |
The curve goes flat almost immediately: level 2 captures 8.1% of 8.9% available, and the remaining eight-tenths of a percentage point cost seven times the compute. This site’s compressor runs level 2, and until this table existed that choice was the upstream default taken on trust; it now stands on measurement.
How these numbers were made
- Encoders: mozjpeg via @jsquash/jpeg 1.6.0; libwebp via @jsquash/webp 1.5.0 (portable, non-SIMD build); oxipng via @jsquash/oxipng 2.3.0. These are the exact WebAssembly binaries the tools on this site run in your browser, not a different build of the same library.
- Corpus: 24 photographs (the Kodak PhotoCD test set), 2 interface screenshots, 1 text-and-table page and 2 graphics, all fixed and hash-pinned.
- Quality score: SSIM and PSNR on BT.601 luma, 11 by 11 gaussian window, computed by our own tested implementation.
- Timings: single-threaded on an Intel Core i7-10510U CPU @ 1.80GHz, single thread, Node v24.13.0. Your device will differ; the shape of the curves is the finding, not the milliseconds.
- Measured: 2026-09-02. The full per-image data is free to download as JSON or CSV, CC BY 4.0.
One honest caveat belongs next to every chart here: SSIM is computed on luma, as the codec literature does, so chroma artefacts, the colour bleeding JPEG’s subsampling causes around saturated edges, are under-counted. Where that bites, the prose above says so rather than letting the number carry more certainty than it holds.
Download the data
Every number on this page, and the per-image rows behind the means, is free to take:
- JSON, with the provenance block included: date, machine, codec builds, metric and the corpus manifest hash, so the file states its own terms.
- CSV, one row per image, codec and quality setting, ready for a spreadsheet.
Licensed CC BY 4.0: use it for anything, credit TabOtter. The photographic corpus is the Kodak PhotoCD test set, released by Kodak for unrestricted use, so results can be compared against the codec literature, which uses the same images.
Limitations
These curves describe one encoder each, at default settings, on a 29-image corpus. They are not claims about Photoshop’s quality scale, which is numbered differently, nor about other JPEG encoders, nor about your particular photograph, which is why the compressor shows you a live preview and measured sizes for your actual image instead of asking you to trust a chart. For choosing between formats rather than within one, the WebP against JPEG comparison is the page with those measurements.