Home · Blog · Resize first, compress second
Resize first, compress second: the order that saves quality
9 Oct 2026 · Images · 7 min read
Ask someone to prepare a photo for a web page and they will usually do two things: make it smaller in dimensions, and make it smaller in file size. Both are sensible. What most people don't realise is that the order of those two operations changes the result — sometimes dramatically. Do them in the wrong sequence and you pay for quality twice while only getting the benefit once.
The correct order is almost embarrassingly simple: resize first, compress second. This article explains why that sequence wins, what goes wrong the other way round, and the exact workflow to use — plus the honest exceptions where the rule bends.
What each operation actually does
It helps to be precise about the two operations, because they damage images in completely different ways. Resizing changes the pixel dimensions: a 4000×3000 photo becomes 1200×900. The software (a process called resampling) looks at the original pixels and computes new ones, blending neighbours together. Done well, with a high-quality resampling filter, this is a clean operation — detail is reduced, but what remains is accurate. The file gets smaller mostly because there are simply fewer pixels to describe.
Compressing, by contrast, keeps the dimensions and reduces the information per pixel. A lossy encoder like JPEG discards fine detail it thinks you won't notice, as described in our guide to lossy versus lossless compression. The image stays 4000×3000, but each 8×8 block is now described more approximately.
Here's the key insight: compression damage is relative to the pixel grid it is applied to. Artefacts introduced at 4000 pixels wide get baked in, and then resizing smears those artefacts across the smaller image — where they become a permanent, slightly-off description of detail that no longer exists. Compress at the final size instead, and the encoder spends its entire budget describing pixels that will actually be seen.
The wrong order, with numbers
Let's make this concrete. You have a 4000×3000 phone photo (about 4 MB as a camera JPEG) and you need a 1200×900 version for a web page, at a small file size. Two paths:
Path A — compress first, then resize. You compress the 4000×3000 original at quality 70, getting roughly a 900 KB file. Then you resize that to 1200×900. The result is about 180 KB. But the quality-70 artefacts — slight blockiness in smooth areas, softened fine detail — were introduced across 12 million pixels and then averaged down. The resized image inherits a faint but permanent mushiness, as if the photo were taken through slightly dirty glass.
Path B — resize first, then compress. You resize the original to 1200×900 first (about 1.1 million pixels — less than a tenth of the original), then compress at quality 70. The result is about 150 KB, and it looks better than Path A's version: edges are cleaner, textures are crisper. The encoder worked directly on the pixels that survived, so every byte of its budget went toward detail you can actually see.
Path B wins on both axes: smaller file, better quality. The difference is modest at high quality settings and becomes obvious at aggressive ones. At quality 50, Path A's output looks distinctly worse — the double damage compounds — while Path B still looks acceptable. The lower you compress, the more the order matters.
Why the wrong order feels natural
If Path B is so clearly better, why does anyone do Path A? Mostly because of how tools present the operations. Many "compress my photo" tools accept your giant original and hand back a smaller file, and only afterwards do you resize it for the page. The compressor did its job faithfully — it just did it on twelve times more pixels than necessary, wasting most of its effort on detail that was destined for the bin.
There's also a psychological trap: compressing first feels productive because the file size drops immediately and visibly. Resizing first feels like a detour. But the file size after resizing alone is already dramatically smaller — our 4000×3000 to 1200×900 resize cut the pixel count by 91%, which typically cuts the file to roughly a tenth even before any compression happens. The "detour" does most of the work.
A quick test you can run yourself
You don't have to take the arithmetic on faith — the whole experiment takes about two minutes with the tools on this site. Take any detailed photo and run it through both paths: first compress the original at quality 60 with the Image Compressor and then resize the result to 800 pixels wide; then start over, resize the original to 800 pixels wide first with the Image Resizer, and compress that at quality 60. Open both results side by side at full size and look at textured areas — foliage, fabric, distant rooftops. The resize-first version will be visibly cleaner at a slightly smaller file size, every time. Once you've seen the difference on your own photo, the rule stops being advice and becomes habit.
The workflow, step by step
Here is the sequence to use whenever a photo needs to end up smaller in both senses:
- Start from the best source you have. The camera original or the least-compressed version available — never a file that has already been through messaging apps or social media.
- Decide the final display size first. How wide will this image actually appear? A page layout that shows images at 800 pixels wide does not need a 4000-pixel file. If the layout is responsive, pick the largest size it will ever display — usually 1200 to 1600 pixels wide for full-width images.
- Resize to that size. Use the Image Resizer with aspect ratio locked, and save the resized version at high quality (or PNG) as an intermediate — this is your new working copy.
- Compress the resized copy. Now run the Image Compressor at quality 75–85 (JPEG or WebP). The quality setting now means what you think it means, because the encoder sees the final pixels.
- Check the result at actual size. View it at the dimensions it will be displayed, not zoomed in. If it looks clean at display size, it is clean.
The honest exceptions
No rule survives contact with reality entirely, so here are the cases where the order matters less or the rule bends:
- You only need one of the two operations. If the image is already the right dimensions and just needs a smaller file, compress away — there is no ordering question. If it just needs smaller dimensions and file size doesn't matter, resize and save losslessly.
- The source is already heavily compressed. If all you have is a much-shared JPEG full of artefacts, resizing first won't remove the existing damage — it just stops you adding more. The rule still holds, but expectations should be modest.
- You're making multiple sizes. Resize the original separately for each target size, then compress each. Don't resize the 1200-pixel version down to 400 pixels — each generation loses a little, so always go back to the largest source.
- Upscaling. If the source is smaller than the target, resizing up invents pixels by interpolation — it cannot create detail that isn't there. No order of operations fixes a 300-pixel image stretched to 1200. (This is also why AI upscalers, which do invent plausible detail, are a different and more dubious category.)
One more caveat worth stating plainly: resizing is itself slightly lossy in practice. Each resampling blends pixels, and repeated resizes accumulate softness — which is why step 3 above says to resize once, from the best source, to each final size directly. The order rule and the single-resize rule are really the same principle: every operation should work on the best available pixels, as few times as possible.