Guide
Fewer pixels, or lower quality?
There are two ways to make an image file smaller: compress the same picture harder, or store fewer pixels. Against a 200 KB ceiling, on five photographs, the two land in very different places.
The experiment
Five photographs, one ceiling: 200 KB. Twice each. First by keeping every pixel and turning the quality dial down until the file fitted. Then by the method this site uses: reduce the dimensions as far as needed to keep the quality at 70 or above.
| Original | Quality only | Dimensions first | Pixels kept |
|---|---|---|---|
| 6240 × 4160 | quality 4 | 1974 × 1316 at q70 | 10% |
| 2160 × 2880 | quality 5 | 726 × 968 at q70 | 11% |
| 2316 × 3088 | quality 31 | 1411 × 1882 at q71 | 37% |
| 1512 × 2016 | quality 24 | 921 × 1229 at q71 | 37% |
| 1503 × 2001 | quality 31 | 1004 × 1337 at q70 | 45% |
Quality 4 is not a photograph. It is a grid of 8 × 8 squares in approximately the right colours, with skies banded into stripes and any text reduced to smears. It is, technically, under 200 KB.
Why the numbers get that extreme
Think in bits per pixel. Across these five photographs, ordinary JPEG at quality 75 used between 0.7 and 2.1 bits per pixel. That is the going rate for a picture that looks like a picture.
Squeezing a 26-megapixel photograph into 200 KB while keeping all its pixels means 0.06 bits per pixel, ten times below the bottom of that band. There is no encoder setting that makes that look acceptable, because there is no room to put anything.
Drop the same photograph to 1974 × 1316 and the budget becomes 0.62 bits per pixel: back inside the normal range, at the low end. Same file size, same 200 KB, one arrives usable and the other does not.
The two losses are not the same kind of loss
This is the part that is easy to miss. Both operations destroy information, but they leave different things behind.
Removing pixels averages neighbours together. Four pixels become one that is their mean. The picture gets smaller and slightly softer, and everything in it stays where it was, in the colour it was. Shown at its new size, it looks correct. You have lost the ability to zoom in, and nothing else.
Crushing the quality invents structure. Coarse quantisation does not gently blur; it snaps whole 8 × 8 blocks to nearby values, producing hard edges along block boundaries, halos around contours, and stair-stepped bands across smooth gradients. None of that was in the scene. The image is now not merely poorer, it is wrong, and conspicuously so.
A picture that is simply smaller still reads correctly. A picture full of compression artefacts reads as damaged. Dimensions are therefore spent before quality.
Where the floor sits, and why 70
Below roughly quality 70, JPEG stops being invisible. Flat areas start to show blocking, edges pick up ringing, and the damage becomes something a viewer notices rather than something they merely fail to appreciate. Above about 85 you are mostly buying bytes: the encoder is preserving detail that will not survive being looked at on a screen.
So the useful band is narrow, roughly 70 to 85, and the sensible strategy is to stay inside it and let the dimensions absorb the rest of the constraint.
Coarse steps waste pixels
Knowing to shrink is not enough; you have to shrink by the right amount. Reducing in fixed steps of 75% removes 44% of the pixels at a stroke, so the first size that fits usually fits with room to spare, and the encoder spends that room on quality nobody asked for. Searching back upward, between the last size that failed and the first that worked, recovers it:
| Photograph | Coarse steps | Refined | Gain |
|---|---|---|---|
| 6240 × 4160 | 1974 × 1316 at q70 | 1974 × 1316 at q70 | none |
| 2160 × 2880 | 683 × 911 at q76 | 726 × 968 at q70 | +13% |
| 2316 × 3088 | 1303 × 1737 at q76 | 1411 × 1882 at q71 | +17% |
| 1512 × 2016 | 851 × 1134 at q76 | 921 × 1229 at q71 | +17% |
| 1503 × 2001 | 845 × 1126 at q81 | 1004 × 1337 at q70 | +41% |
Up to 41% more pixels for exactly the same file size, purely by not stopping at the first size that worked. The one photograph that gained nothing had landed on a good step by luck.
Content decides, not megapixels
Notice that the 2316 × 3088 photograph kept 37% of its pixels while the 1503 × 2001 one kept 45%, despite being much larger. Megapixels are a weak predictor. What matters is how much detail is in the frame.
A portrait against a plain wall is mostly smooth gradient, which JPEG stores almost for free, so it keeps most of its size. A street scene full of foliage, brickwork and signage is expensive everywhere, and has to shrink much further to fit the same budget.
This is why a fixed rule like "always halve it" is unhelpful, and why the tool searches per image instead of applying a preset.
When the target simply cannot be met
Aim the same five photographs at 50 KB and the 26-megapixel one fails outright: there is no size above the 200 px minimum at which it fits while holding quality 70. The others land between 330 × 440 and 641 × 855.
Faced with that, a tool has two reasonable options: say it cannot be done, or break the quality floor deliberately and report it. Handing back a file that is still over the limit without saying so helps nobody.
Rules of thumb
- Set the dimensions the destination actually needs before worrying about bytes. A 4000 px photograph shown 800 px wide is 96% waste no matter how well it is compressed.
- Never go below quality 70 to hit a target. Take the pixels instead.
- Do not chase quality 95. On an already-compressed file it can make things larger, not better.
- If a form asks for both a pixel limit and a size limit, give both at once. Fitting the box first leaves the compressor an easier job.
Try it on your own photo: compress to a file size →