Is it better to resize or compress an image?
Resize first — we produced the same file size both ways and measured the difference, and it grows the smaller your budget gets.
By Free Image Lab ·
The short answer
Resize first, then compress. They are not competing options, they are two steps of one job, and doing them in that order gives a better result than either one pushed to its limit.
If you only do one, resize. We tested this properly rather than repeating the received wisdom: same photograph, same target file size, reached two different ways, then both compared against the original at the size a viewer would actually see. Resizing won all three times, and the margin grew as the budget tightened.
What each one actually does
- Resizing changes how many pixels there are
- Going from 4000 pixels wide to 1600 averages groups of neighbouring pixels into single ones. The image holds less detail, but every pixel it keeps is honest. Nothing is approximated, so nothing looks damaged.
- Compressing changes how precisely each pixel is stored
- The pixel count stays the same. What changes is how much the encoder is allowed to round off, and rounding is what produces the blocky patches and smeared edges people recognise as a badly compressed image.
That difference is the whole argument. Resizing removes detail you were never going to display. Compressing degrades detail you are still showing. The first is free in visual terms and the second is not.
The test
A 4000 × 3000 photograph, destined to be displayed 1600 pixels wide, which is the ordinary case for a full-width web image.
Two routes to the same file size:
- Resize: reduce to 1600 × 1200, then save at a moderate quality.
- Compress: keep all 4000 × 3000 pixels, and lower the quality until the file matches the first one.
Both were then compared against a reference: the untouched original scaled to 1600 × 1200 with no compression at all. That is the fair comparison, because it measures what the viewer ends up looking at rather than what is stored in the file. Error is the average change per colour channel on the 0–255 scale, so lower is better.
| Budget | Route | Settings | Actual size | Error |
|---|---|---|---|---|
| ~190 KB | Resize | 1600×1200, q85 | 193 KB | 2.02 |
| Compress | 4000×3000, q22 | 190 KB | 2.71 | |
| ~95 KB | Resize | 1600×1200, q70 | 95 KB | 2.36 |
| Compress | 4000×3000, q10 | 95 KB | 4.47 | |
| ~50 KB | Resize | 1600×1200, q50 | 50 KB | 2.65 |
| Compress | 4000×3000, q1 | 78 KB | 13.34 |
Resizing was better at every budget, by 1.3×, 1.9× and 5× respectively. The pattern is the useful part: at a generous budget the two routes are fairly close, and the tighter the budget gets, the more decisively resizing wins.
One honest complication. At the most generous budget, the compressed full-size image had a slightly lower worst pixel error than the resized one, 59 against 73, even though its average was worse. That is not noise, it has a cause: shrinking a heavily compressed image averages its artifacts away, so nothing ends up dramatically wrong while everything ends up slightly wrong. The resized version keeps a few large errors along the hard edges of text. At ordinary viewing that trade still favours resizing, but it is a trade rather than a clean sweep, and at the two tighter budgets the compressed version loses on both measures anyway.
Compression has a floor. Resizing does not.
Look at the last row again. Asked for 50 KB, the full-resolution route returned 78 KB — fifty-six percent over budget — at quality 1, the lowest setting the encoder has. It could not go smaller. And for that it produced an image five times further from the original than the resized one.
This is the part people do not expect. A JPEG has an irreducible cost per pixel: even storing nothing useful about a pixel takes some bytes, and twelve million pixels means twelve million of those costs. Turning the quality dial to zero does not get you past it.
Resizing attacks the pixel count itself, so it never runs out of room. If you have ever fought a “maximum file size 2 MB” upload form by dragging the quality slider further and further left while the file refuses to shrink, this is what was happening.
If you are stuck under an upload limit
Reduce the dimensions rather than the quality. Our image resizer shows the resulting file size next to the original, so you can find the dimensions that fit the limit before you touch a quality setting at all.
Doing both, in the right order
- Decide how large it will actually be displayed. 1600 pixels wide is generous for a full-width web image; 800 is plenty for something sitting in a column.
- Resize to that. This is the step that does the heavy lifting and costs nothing visually.
- Then compress, at quality 80 to 85. Judging quality before resizing means judging an image that is about to change.
- Then strip metadata if you need the last few percent.
Also worth remembering: cropping removes pixels too. If a third of the frame is empty ceiling, cutting it costs nothing at all and improves the photograph.
When resizing is the wrong move
- It is your only copy
- Resizing is not reversible. Enlarging cannot recover detail that averaging removed. Keep the original somewhere and resize a copy.
- It will be printed
- Print needs far more pixels than a screen. A photo that looks generous at 1600 pixels wide on a monitor is roughly a 13 centimetre print at normal print resolution.
- Someone will zoom into it
- Product photography, artwork, anything where detail is the point. Here the dimensions are the product, so compression is the only lever you have.
- It is already the right size
- If the file is large at sensible dimensions, the cause is something else — usually sensor noise, or a quality setting near 100. Both are covered in why is my JPEG so big.
Frequently asked questions
- Is it better to resize or compress an image?
- Resize first, then compress. We produced the same file size both ways and compared them against the original at the size a viewer would actually see it. Resizing was better every time, and the gap widened as the file budget got tighter: about 1.3 times better at 190 KB, 1.9 times at 95 KB, and 5 times at 50 KB. The two are not alternatives, though. Doing both, in that order, beats either alone.
- What is the difference between resizing and compressing?
- Resizing changes how many pixels the image contains, by averaging neighbouring pixels together into fewer of them. Compressing keeps every pixel but stores each one less precisely. Resizing removes information you were not going to display anyway. Compressing degrades information you are still showing, which is why it becomes visible first.
- Does resizing an image reduce quality?
- Making an image smaller does discard detail, but it discards it by averaging rather than approximating, so the result stays clean and sharp at its new size. There are no blocky artifacts, no smeared edges and no halos. The quality only becomes a problem if you later need the image larger again, because enlarging cannot recover what averaging removed. Keep the original.
- Can compression alone get a photo small enough?
- Not always, and that surprises people. In our test a 4000 by 3000 photo could not be compressed below 78 KB even at the absolute minimum quality the encoder allows, because a JPEG has an irreducible cost per pixel no matter how hard you push. Resizing the same photo to 1600 by 1200 reached 50 KB comfortably at a moderate quality setting, and looked five times closer to the original while doing it.
- Should I resize before or after compressing?
- Before, always. Compressing first means you spend effort preserving detail you are about to throw away, and then you judge the quality setting against an image that is about to change. Resize to the dimensions you will actually display, then choose a quality setting, then look at the result.
Tools for this
Free, and everything runs in your browser.