2026-10-07
Compress vs resize is the question most people hit right after an upload gets rejected. Both make a file smaller, and that is where the similarity ends. Resizing throws away pixels and leaves what remains untouched. Compression keeps every pixel and changes how those pixels are stored. Pick the wrong one and either the file stays over the limit or the image goes soft. The numbers below come from one ordinary photo, so you can see where each step actually lands.
Resizing changes how many pixels the image holds. Going from 4000 x 3000 to 1200 x 900 resamples the grid once, and everything that lived between the surviving samples disappears. No tool brings it back. The pixels that remain were not re-encoded, which is why edges and small text stay crisp.
Compression leaves the pixel grid alone and works on how those pixels are stored. Lossy formats like JPEG and WebP drop detail that human vision struggles to resolve. Lossless formats like PNG only remove statistical redundancy, and decompression returns the exact bytes. Push the quality setting far enough and the artefacts stop hiding.
These figures use a straight-out-of-camera 4000 x 3000 holiday photo. They are the magnitudes you normally see for this kind of file, not a universal result.
The last two rows settle the argument. Resize once and compress once gives the smallest file and acceptable sharpness. Compressing the same file three times leaves it larger and worse looking.
Work backwards from where the image ends up. If the layout shows it 800 pixels wide, there is nothing to discuss: resize first, then apply one light compression pass.
Most quality complaints trace back to these rather than to the codec. Related reads sit at /blog/lossy-vs-lossless-compression, /blog/resize-and-compress-image, and /blog/compress-jpg-under-100kb.
It depends on the size you judge it at. The surviving pixels were not re-encoded, so the image is clean at its target size. The discarded detail really is gone, and enlarging shows soft edges. The useful test is the viewing size, not absolute sharpness.
Resize to the size it will actually be used at, usually around twice the displayed width, then compress once. Reverse the order only when the pixel dimensions have to survive, such as screenshots with text or files heading to print.
No. Enlarging interpolates from neighbouring pixels, so the pixel count comes back and the detail does not. That is why the full-size file has to be kept before anything gets resized.
Resizing only cuts the pixel count once. If the source was encoded inefficiently, or carries an alpha channel, metadata, and embedded previews, the result stays heavy. One compression pass after resizing usually takes another half off.