What Actually Controls Image File Size?
One photograph, one screenshot, 24 measured encodes. The quality slider is not the control you think it is.
Short answer: dimensions dominate. Halving an image's width and height cut the file to 21% of its original size while keeping full per-pixel quality. Getting the same saving from the quality slider alone would mean dropping below quality 10. And on a screenshot, lossless WebP was 18 times smaller than JPEG — while also being lossless.
Method
Two sources, both 927 × 1648 pixels (1.53 megapixels), so that every figure is directly comparable:
- Photograph — a real photo, 91,009 distinct colours, continuous tone throughout.
- Screenshot — flat background, hard-edged boxes and anti-aliased text, the content class JPEG is worst at.
Each was encoded with Pillow 11.3 across 13 JPEG quality levels, 6 scale factors and 5 format settings, and the output measured in bytes. One caveat worth stating: the photograph came from an existing JPEG, so the "quality 100" figure is a re-encode rather than a camera original. That affects the absolute numbers slightly and not the shape of the curve. KB means 1024 bytes.
The quality curve, and where it turns
| Quality | Photograph · Screenshot · photo as % of q95 |
|---|---|
| 10 | 45.7KB · 73.5KB · 6% |
| 30 | 102.5KB · 130.8KB · 14% |
| 50 | 159.6KB · 170.1KB · 22% |
| 70 | 238.1KB · 214.2KB · 32% |
| 80 | 320.4KB · 250.4KB · 44% |
| 85 | 401.3KB · 277.7KB · 55% |
| 90 | 567.2KB · 326.9KB · 77% |
| 95 | 732.8KB · 414.6KB · 100% |
| 100 | 1268.1KB · 659.4KB · 173% |
The curve is far from linear. From 80 to 85 costs 81KB. From 90 to 95 costs 166KB. From 95 to 100 costs 535KB — more than the entire file at quality 80.
Quality 100 is the single most wasteful setting in image editing. It is not lossless; it simply stops JPEG from doing the job it exists to do. Four times the bytes of quality 80, for a difference you will not find without pixel-peeping a side-by-side.
At the other end, below about 50 the savings flatten — going from 30 to 10 saved only 57KB — while the artefacts keep getting worse. The useful range is roughly 60 to 85, and 80 is a reasonable default.
The main event: dimensions versus quality
This is the comparison that matters, and it is not close. All at JPEG quality 80, unchanged.
| Scale | Pixels · File · % of original |
|---|---|
| 100% | 1,527,696 · 320.4KB · 100% |
| 75% | 859,020 · 163.9KB · 51% |
| 50% | 381,512 · 67.6KB · 21% |
| 35% | 186,624 · 31.5KB · 10% |
| 25% | 95,172 · 15.6KB · 5% |
| 12.5% | 23,690 · 4.2KB · 1% |
Note that the file shrinks slightly faster than the pixel count: at 50% scale, 25% of the pixels remain but only 21% of the bytes, because a smaller image also compresses more efficiently per pixel.
Now put the two controls side by side at the same target:
- Quality 80 → 50: 320.4KB → 159.6KB. Every pixel in the image is now degraded.
- Scale 100% → 75%: 320.4KB → 163.9KB. Essentially the same saving, and the remaining pixels are untouched at quality 80.
- Scale 100% → 50%: 320.4KB → 67.6KB. 2.4 times better than the quality drop, still at quality 80.
To reach 67.6KB with the quality slider alone you would have to go below quality 10, which produces an unusable image. Resize first, then compress — and if the image is going into a web page at 800 pixels wide, a 4000-pixel source is not giving you anything the viewer can see.
Format depends entirely on what the picture is
| Format | Photograph · Screenshot |
|---|---|
| JPEG q80 | 320.4KB · 250.4KB |
| JPEG q95 | 732.8KB · 414.6KB |
| WebP q80 | 334.0KB · 110.7KB |
| WebP lossless | 1530.3KB · 13.9KB |
| PNG | 2192.0KB · 227.9KB |
Two findings here, and one of them contradicts the usual advice.
WebP was not smaller than JPEG on the photograph. At the same nominal quality of 80 it came out slightly larger, 334KB against 320KB. This does not mean WebP is worse — it means the two formats' quality numbers are not the same scale, so setting both to 80 does not compare like with like. Treat any "WebP is 25–35% smaller" claim as being about matched visual quality, which a single number on a slider does not give you.
On the screenshot, lossless WebP was 13.9KB. Against 227.9KB for PNG — 16 times smaller — and against 250.4KB for a lossy JPEG that also looks worse. If you take one practical thing from this article: screenshots and diagrams belong in lossless WebP, PNG if you need universal support, and never JPEG.
The reverse holds for photographs: PNG at 2192KB is nearly seven times the JPEG, for a difference nobody can see in a photograph.
Hitting an exact size limit
The tables above show why a quality percentage cannot target a file size: at quality 80 the photograph was 320KB and the screenshot 250KB, from identical dimensions. The same setting, a 28% difference in result. Multiply that across arbitrary images and a form demanding "under 200KB" cannot be satisfied by picking a number on a slider.
The approach that works is to search: encode, measure, adjust, repeat until you are just under the limit — and reduce the dimensions when even the lowest quality overshoots, since the tables show that is where the real capacity is. That is what compress to size does, in your browser, and there is a fuller write-up in compressing to an exact size.
What to take from this
- Resize before you compress. Measured 2.4× more effective, with no per-pixel loss.
- Never use quality 100. Four times the size of 80, not lossless, no visible benefit.
- Stay between 60 and 85. Outside that range you are either wasting bytes or adding artefacts for nothing.
- Screenshots and logos: lossless WebP. 16× smaller than PNG here, and lossless.
- Photographs: JPEG or lossy WebP. PNG costs seven times as much for no gain.
- Need an exact KB figure? No slider setting will reliably hit it — use a tool that searches for it.
Related guides
- Reducing image file size — the practical walkthrough
- JPEG vs PNG vs WebP — what each format is built for
- Compressing to an exact size — 200KB, 100KB, 50KB
- Does re-saving lose quality? — measured, and the answer differs for images and audio
Summary
The quality slider is the control everyone reaches for and the weaker of the two. Dimensions decide most of the file size, and reducing them costs nothing when the image is displayed smaller than it is stored. Beyond that, match the format to the content: continuous tone to JPEG or lossy WebP, flat colour and text to lossless WebP or PNG. Getting that pairing wrong costs more than any slider setting can recover.