Resizing versus compressing an image

These two words get used interchangeably and they are completely different operations with different costs.

Resizing changes how many pixels the image has. A 4000×3000 image resized to 2000×1500 has a quarter as many pixels, and roughly a quarter of the file size.

Compressing keeps the pixel count and describes each block of pixels less precisely. A 4000×3000 image at quality 0.6 instead of 0.9 has exactly as many pixels, stored more cheaply.

The reason the distinction matters: resizing is free when done correctly, and compressing never is.

Why resizing can be free

An image only has to contain as many pixels as whatever displays it will show. Everything beyond that is discarded at display time regardless.

If a form shows your photograph in a 400-pixel-wide box, a 4000-pixel-wide upload has 90% of its pixels thrown away by the browser after you paid to send them. Resizing to 800 pixels — generous, double the display size for a retina screen — produces an identical-looking result and a file 96% smaller.

That is not a quality trade-off. It is removing bytes that were never going to be seen.

The cost only appears when you resize below the display size. Then the browser scales back up, and softness becomes visible. So the rule is: resize to the largest size anything will actually use, and no smaller.

Why compressing always costs something

JPEG and lossy WebP work by discarding detail. At quality 0.85 what goes is almost entirely sensor noise, so you cannot see it. At 0.5 what goes includes real edges, and you can.

The loss is also permanent and cumulative — each save re-quantises, and the next save treats the previous one's artefacts as detail worth keeping. That accumulation is the most common way people destroy a photograph while trying to shrink it.

So compression is a dial with a real cost at every position. Resizing, up to a point, has none.

Which to reach for, with the arithmetic

File size scales roughly linearly with pixel count, and roughly with the square root of the quality setting's effect. In practice:

Operation	Pixel count	Typical size	Visible?
Original, 12MP, q0.92	4032×3024	4.1MB	—
Quality to 0.80	4032×3024	1.6MB	No
Quality to 0.60	4032×3024	900KB	Slightly
Quality to 0.40	4032×3024	580KB	Yes, badly
Resize to 1600, q0.92	1600×1200	710KB	No
Resize to 1600, q0.80	1600×1200	310KB	No
Resize to 800, q0.80	800×600	95KB	Only below 800px display

Look at rows four and six. Both land near 500KB. One is visibly damaged at full resolution; the other is indistinguishable from the original at the size it will be shown. Same byte count, completely different outcomes — and the difference is entirely which dial you turned.

The order, and why it is not negotiable

Resize first, compress second. Always.

Compressing first and resizing afterwards is the worst case: you pay the quality cost of compression, then throw away the pixels you paid to compress, then usually have to compress again because the resize changed the size unpredictably. Two lossy passes for the result one would have given.

Resizing first also makes the compression pass cheaper and more predictable, because there is less high-frequency noise left to decide about.

When resizing is not available

Sometimes the dimensions are fixed for you, and then compression is the only dial left:

• A form specifies pixel dimensions. Exam and visa portals routinely demand exactly 600×600 or a range like 200×230 to 400×500. Those specifications are the whole spec, not just a byte cap, and the dimensions are not yours to choose.
• Text must stay legible. A scanned document needs its pixels more than it needs precision in each one, so for text you keep resolution and drop quality — the reverse of the advice for photographs.
• It is going to print. 300dpi at the physical size is a hard floor.

In those cases a byte target has to be hit with quality alone, which is exactly the situation where guessing a quality setting fails and measuring works.

Hitting a specific number

The awkward fact is that neither dial predicts file size reliably. A photograph of a brick wall and a photograph of a blank sky, at identical dimensions and quality, differ by a factor of four — because one is full of high-frequency detail and the other is nearly flat.

So a tool that applies "quality 0.7 for a 100KB target" is guessing, and it will miss in one direction or the other on most images. An image encode costs about fifteen milliseconds, which is cheap enough to simply try, weigh the output, and adjust:

1600 x 1200   quality 0.90   →  290KB   over 100KB
1600 x 1200   quality 0.55   →   96KB   under, best so far
1600 x 1200   quality 0.62   →  112KB   over
1600 x 1200   quality 0.58   →  103KB   over
1600 x 1200   quality 0.56   →   99KB   under, and the best found

Compress an image to 100KB, to 50KB or to 200KB resizes down the sensible ladder first and then bisects quality against the real byte count, so the result is the best-looking file that actually measured under your number. In your browser — the image is not uploaded.

FAQ

Does resizing an image reduce its file size?

Yes, and usually more than compression does. File size scales roughly with pixel count, so halving both dimensions cuts about three quarters of the file. It is also free in practice as long as the result is still at least as large as whatever will display it, because those extra pixels were being discarded at display time anyway.

Is it better to resize or to lower the quality?

Resize first, then lower quality — in that order, and resizing should do most of the work. A photograph resized to 1600 pixels at quality 0.80 and the same photograph left at 4032 pixels at quality 0.40 can be the same number of bytes, but the first looks like the original and the second is visibly blocky.

What dimensions should I resize to?

The largest size anything will actually display, doubled if it may be shown on a high-density screen. For a form that shows a photo in a 400-pixel box, 800 pixels is generous. For a full-width web image, 2560 covers almost everything. If a form specifies dimensions, use those — they override every other consideration.

Why does my image stay the same size when I lower the quality?

Usually because it is a PNG. PNG is lossless and has no quality dial, so a quality slider in some editors does nothing at all for it. To make a PNG smaller you either resize it, reduce its colour palette, or convert it to a lossy format — which for a photograph is what you wanted anyway.