Someone tells you the images are too big. You now have to work out which kind of big they meant, because there are two and the fix is different for each.

Dimensions and file size are not the same thing

Resizing changes the pixel dimensions. A 4032 × 3024 photo becomes 1200 × 900. You have thrown away roughly nine tenths of the pixels, and they are not coming back.

Compressing changes what the file weighs. That same 4032 × 3024 photo stays 4032 × 3024, but the file drops from 8 MB to under 1 MB because the pixels are stored more efficiently.

Both make “the image smaller”. Only one of them is reversible in any meaningful sense, and only one of them is usually what the problem called for.

When you genuinely need to resize

Less often than you would think, but it does happen:

  • A platform demands exact dimensions. App store screenshots and ad units are rejected outright at the wrong size.
  • You are shipping a thumbnail. Sending a 24-megapixel file to be displayed at 300 pixels wide wastes bandwidth no encoder can recover.
  • A form has a hard pixel limit. Passport photo uploads, some CMS fields.

If you need target dimensions, our reference of common image sizes lists what each platform expects — social, web, print, and both app stores — with every ratio drawn to scale.

When compression is the answer

Nearly everywhere else. If the complaint is that a page loads slowly, an email bounced, or a folder will not fit somewhere, the problem is bytes and not pixels. Compressing solves it while leaving the image intact for whatever you need next.

This is also the reversible-ish choice. Keep the original and you can always re-export at a different level. Resize and save over the file, and the detail is gone for good.

What SqueezeImages does, and what it does not

Worth being straight about this, because the two words get muddled constantly: SqueezeImages compresses. It does not resize. Your dimensions come out exactly as they went in — a 4032 × 3024 photo is still 4032 × 3024 when it lands in the output folder.

That is a deliberate choice rather than a missing feature. Resizing is a decision about how an image will be used, and it belongs with the person making that decision — usually in the editor or export dialogue where you can see the crop. Compression is a mechanical step at the end that should apply the same way to everything. Mixing the two into one button is how people end up with a folder of pictures quietly downscaled to the wrong dimensions.

If you need both, do them in this order

Resize first, compress second. Always.

Compressing and then resizing means you carefully optimised pixels you were about to throw away, and the downscale then re-samples the artefacts you just baked in — smearing them across the smaller image. Doing it the other way round means the encoder is working on the final pixels, which is where the quality budget belongs.

So: crop and resize in whatever tool you already use, export, then run the folder through compression on the way out. The guide to compressing without losing quality covers picking a level once you get there.

The short version

  • Page is slow, email bounced, folder too large → compress.
  • Platform rejected the file for its dimensions → resize.
  • Both → resize first, then compress.
  • Not sure → try compressing. It is the one you can undo by keeping the original.

SqueezeImages is free to download and runs entirely on your own machine. More on why that matters.