What Image Quality Setting Should You Use? A Benchmark

Most people leave the quality slider at 80 or 90 without thinking about it. Some set it to 100 to “avoid losing anything.”

Quality 100 should never be used. It produces a file roughly three times larger than quality 90 while improving measured quality by about one percent. To find where the payoff actually stops, I encoded images from this blog at every quality step from 30 to 100 and measured both size and quality.

Photographs and screenshots turned out to need completely different settings. More surprisingly, JPEG quality does not increase monotonically on screenshots — raising the slider actually made the image worse at two points.

How the measurement was done

Four photographs and one screenshot from this blog were resized to 1920px on the long edge, then encoded at quality 30 through 100 in steps of 10.

▼Test setup

Differences become hard to see above roughly SSIM 0.98, so read the tables below with that threshold in mind.

Format-to-format comparison is covered separately in the JPEG, WebP and AVIF benchmark. This article is about what to do once the format is settled.

Result 1: JPEG quality steps on photographs

Quality 100 costs 2.7 to 3.0 times the file size of quality 90 and returns about 0.01 in SSIM.

Each cell shows file size / SSIM.

▼What happens from q90 to q100

Triple the bytes for one percent of quality. No image on the web justifies that trade. Quality 100 pays almost the cost of lossless compression without being lossless.

Result 2: WebP quality steps on photographs

WebP behaves the same way. Quality 100 costs 2.0 to 2.3 times quality 90.

One detail deserves attention: WebP at q80 is lower quality than JPEG at q80. On the food photograph, JPEG scored 0.971 against WebP’s 0.964. Quality numbers mean different things in different formats, so carrying your old JPEG setting straight over to WebP quietly lowers image quality.

For photographs in WebP, set the value 5 to 10 points higher than the JPEG value you were using.

Result 3: the payoff stops around quality 70–80 for photographs

Efficiency holds up to about q80 and falls off sharply beyond it. Photographs belong at 70–80.

Tracking the cost of each 10-point step makes the boundary obvious. This is the food close-up in JPEG.

The same 0.014 improvement costs 188KB between 80 and 90, and 1013KB between 90 and 100. More than five times the price for identical returns.

▼Suggested values for photographs

Result 4: screenshots need completely different settings

A screenshot reaches SSIM 0.984 at WebP quality 30. Setting it to 80 out of habit wastes 1.7 times the bytes.

The same measurement on a game screenshot, in WebP:

Photographs scored 0.907 to 0.963 at quality 30. The screenshot scored 0.984. Images built from flat colour and straight lines simply do not fall apart at low quality.

For a site that publishes screenshots heavily, splitting this setting away from the photograph setting noticeably reduces total page weight.

Result 5: JPEG quality is not monotonic on screenshots

Raising JPEG quality on a screenshot lowered measured quality at two separate points. That alone rules JPEG out for UI images.

The screenshot encoded in JPEG at 5-point steps:

At q40 and q70 the file grew while SSIM fell. q35 (0.9682) beat q40 (0.9531), and q65 (0.9808) beat q70 (0.9649).

To isolate the cause, the same encodes were repeated with chroma subsampling fixed at 4:4:4. The dips appeared in exactly the same places (0.9544 at q40, 0.9658 at q70). Chroma is not responsible; the luminance quantisation tables are.

JPEG maps the quality value onto a scaling factor for its quantisation tables, and at certain values the high-frequency coefficients that carry text edges get quantised more coarsely. On photographs this hides in the noise. On images full of hard edges, it shows up in the measurement.

▼What follows from this

Quick reference

Splitting settings by “photograph or interface” covers almost every case.

Screenshots are listed at native size because downscaling a UI image makes its text unreadable. Photographs survive resizing; interfaces do not. Reduce UI images through format and quality, never through resizing.

Trying it yourself

The batch image converter on this blog takes a quality value from 1 to 100 and converts multiple files at once. Nothing is uploaded; the work happens inside the browser.

▼The three presets, read against this measurement

When converting screenshots, skip the presets and pull quality down to 40–60. If your images behave like the ones measured here, the file will be roughly half the size with no visible change.

Related reading

▶ JPEG, WebP and AVIF measured at matched quality — which format to pick in the first place

▶ Handling WebP files comfortably on a Mac — opening WebP on macOS

▶ Building an image compression GUI in Python — automating the same job on the desktop

Summary

Three conclusions came out of the measurement.

▼Conclusions

The genuinely unexpected finding was JPEG’s non-monotonic behaviour. On screenshots there are quality values where turning the slider up makes the image measurably worse. The assumption that a higher quality setting always produces a better result does not hold for text-heavy images.

Stop treating photographs and interface images with the same settings. That is what this measurement really amounts to.

Measurements were produced with the Pillow 12.3.0 encoders. Other encoders such as cwebp or mozjpeg will shift the numbers, including where the dips occur. SSIM approximates perceived quality and does not perfectly match what the eye sees.