Resize or Compress? The Difference Between an Image's Dimensions and Its File Size

Someone asks you to make an image smaller and there is no way to know which thing they mean. They might want it to take up less room on the page. They might want the file to fit under an upload limit. These are different problems with different solutions, and confusing them is the single most common reason an image stays too heavy after somebody has spent twenty minutes trying to fix it.

Two meanings of "smaller"#

Dimensions are how many pixels the image contains: 4032 × 3024, say, which is a typical iPhone photograph. This determines how large the image can be displayed before it starts to look soft.

File size is how many bytes the image occupies on disk: 3.8 MB, perhaps. This determines how long it takes to send, upload or download.

The two are related but not the same, and the relationship is not linear. Halving the width of an image quarters the pixel count, because you halved both dimensions — a 4000 × 3000 photograph has twelve million pixels, and at 2000 × 1500 it has three million. That is usually a much larger saving than anything the quality slider will give you.

Why the quality slider disappoints#

Here is the pattern that brings people to a compression tool in the first place. A photograph is 4 MB. They open a compressor, drag quality from 90 down to 60, and get 1.9 MB. They drag it to 40 and get 1.4 MB, and now the sky has visible banding. They give up and conclude compression does not work very well.

What went wrong is that the image is still 4032 pixels wide. The quality slider is being asked to solve a problem it cannot reach. Twelve million pixels have to be encoded no matter how aggressively each one is approximated, and the format has a floor below which it simply cannot go without becoming ugly.

Resize the same photograph to 1600 pixels wide first and it will drop to somewhere near 400 KB at a quality of 80 — better looking than the 40-quality version, and a quarter of its size. The pixels you removed cost nothing to remove, because they were never going to be seen.

The order matters#

Resize first, then compress. Two reasons, and the second is the one people miss.

The obvious reason is efficiency: compressing pixels you are about to delete is wasted work.

The less obvious reason is quality. Every lossy encode is a permanent approximation. If you compress at 4000 pixels and then resize to 1600, you have encoded twice — once badly, then again on top of the first encode's artefacts. Resizing first means one encode, on the pixels you are actually keeping.

Our image compressor does both in one pass for this reason: choose a longest-edge limit and a quality together, and the resize happens on the canvas before a single byte is encoded.

How many pixels do you actually need?#

This is the question almost nobody asks, and it decides everything.

For a screen, the answer is roughly twice the display width. An image shown in a 600-pixel-wide column wants about 1200 pixels of source, so that it stays sharp on a high-density display where each CSS pixel is drawn with two or more device pixels. Beyond that you are downloading data the screen cannot show.

For print, the arithmetic is different and dimensions alone tell you nothing. Printers work in dots per inch, so what matters is pixels divided by physical size. A 300 dpi target means a photograph printed six inches wide needs 1800 pixels. The same 1800-pixel file that is generous for a web page is exactly adequate for a small print and badly short for a poster.

For an upload limit, neither of these applies — you have a byte ceiling and you need to hit it. That is the one case where working backwards from the file size makes sense, and it is why our compressor has a mode that takes a target size and finds the highest quality that fits under it, rather than making you guess at the slider.

What resizing actually does to the image#

Resizing down is called downsampling, and it is a genuine loss: information is discarded and cannot be recovered. But it is a clean loss. A well-resized image looks correct at its new size, with no artefacts — it simply contains less detail than it did, which is fine, because the detail was not being displayed.

The practical consequence is one habit: keep the original. Resize a copy. You will eventually need the large version for something — a print, a different layout, a client who asks for the full-resolution file — and there is no way back once you have overwritten it.

Resizing up is a different matter. You cannot add detail that was never captured. Enlargement interpolates: it invents intermediate pixels by averaging their neighbours, which produces softness at small factors and visible mush at large ones. AI upscalers do better by generating plausible detail, which is a genuine improvement for a decorative image and an active problem anywhere accuracy matters — the detail it adds was not in the original scene.

Where this shows up in your Core Web Vitals#

If you run a website, the resize-versus-compress distinction has a direct cost. Largest Contentful Paint measures how long the biggest visible element takes to render, and on most pages that element is an image. An oversized hero image delays LCP by the time it takes to download the bytes nobody needed.

Serving a 4000-pixel image into a 1200-pixel slot is not merely wasteful. On a phone on a slow connection, it is the difference between a page that feels immediate and one that does not. Our guide on image optimisation and Core Web Vitals works through what the metrics actually measure and which decisions move them.

The proper fix for a website is not one resized image but several, served through srcset so that each device downloads the size it can use. That is more work than one file, and it is the difference between a site that is fast on desktop and one that is fast on a phone.

A working sequence#

For a photograph headed to a web page or an email:

1. Decide the display width. Where will this appear, and how wide is that space?
2. Double it. That is your target pixel width for a screen.
3. Resize to that width, from the original file.
4. Choose a format. WebP for the web, JPEG if it has to open anywhere.
5. Compress once, at a quality around 75–85, and look at the result.
6. Keep the original somewhere you will find it again.

Steps 3 to 5 are one operation in a good tool. The thinking is in steps 1 and 2, and it takes about fifteen seconds — which is considerably less than the twenty minutes usually spent dragging a quality slider back and forth on an image that was four times too large to begin with.