Reduce Image Size Without Losing Quality: The Real Rules

The short version: shrinking an image barely costs you anything. Removing pixels does not harm the pixels that stay, so a 4000px photo going down to 1200px is close to free, and at normal viewing size you will not see the difference.

Which makes "reduce image size without losing quality" a strange thing for roughly 5,400 people a month to search, until you notice that half of them mean something else entirely.

Some want fewer pixels. Some want fewer kilobytes. Those are different jobs with different tools and, annoyingly, opposite answers to the quality question. So let us split them apart first, then get into the part that actually ruins images, which is neither of the things you are worried about.

"Image size" means two different things

They are related but not the same, and the confusion costs people real time. Resizing does shrink the file as a side effect, often dramatically, because a quarter of the pixels is roughly a quarter of the data. But it will not hit a specific number in KB, and no amount of resizing gets a PNG under a limit that only accepts JPG.

Rule of thumb for which one you need:

That last row is the common one, and the order matters. Compressing first means spending your quality budget on pixels you are about to delete. We wrote up the file-size half of that job separately in how to reduce image size to 25 KB.

The rest of this piece is about the dimensions half.

Why you can reduce image size without losing quality

Here is the bit that surprises people: downscaling is not really a lossy operation in the way compression is.

When you go from 4000 pixels wide to 1000, the tool is not damaging your photo. It is computing 1000 new pixels, each one an average of the source pixels that fell into its area. The information in those averages is real. Nothing is being guessed at.

Upscaling is the opposite, and it is where the quality anxiety actually belongs. Going from 400 pixels to 4000 means nine out of every ten pixels in the result were never captured by a camera. They are interpolated: a plausible smear between the neighbours that did exist. That is why enlarged images look soft and slightly plastic, and no setting fixes it, because the detail is not hiding somewhere waiting to be recovered. It was never there.

The blurry-resize problem nobody names

So if downscaling is nearly free, why does everyone have a story about a resized image coming out soft?

Because of how the reduction was done, and this is the part every other guide on this subject skips entirely.

Browsers, and most simple online resizers, draw the source image into a smaller canvas in one move. The catch is that this sampling reads a small fixed neighbourhood around each output pixel. Do a modest reduction and that is fine. Do a big one, say 4000 pixels down to 400, and each output pixel is derived from a tiny patch of a region ten pixels wide. Roughly one source pixel in nine contributes anything at all. The other eight are not blended in. They are skipped.

That is why the result looks thin and slightly aliased rather than smoothly soft. It is not blur. It is missing information, and it hits exactly the things you notice: text, hairlines, the edges of a logo, fine texture in a landscape.

The fix is unglamorous. Instead of one big jump, halve the image repeatedly and make the final short step at the end:

1. 4000 → 2000

   Every pixel in the 2000px version is an average of four real source pixels. Nothing skipped.

2. 2000 → 1000

   Same again. Each pixel now carries information from sixteen original ones.

3. 1000 → 400

   The last step is small enough that the browser's own sampling reads everything it needs.

The whole chain costs a few extra milliseconds and it is the difference between a sharp thumbnail and a mushy one. Photoshop has done a version of this for years, which is what "Bicubic Sharper (reduction)" is for; MDN documents the imageSmoothingQuality hint that browsers expose, though on its own it does not solve the big-jump problem.

Our image resizer steps down in halves automatically. You will never see it happen; you will just notice the 400px version still has readable text in it.

Change image dimensions without stretching anything

The second most common way to wreck an image is to squash it, and it happens because someone typed both numbers.

An aspect ratio lock is the checkbox that stops this. With it on, you type one side and the tool derives the other from your original's proportions. Every image size changer worth using has it, and it should be on by default.

Three operations get muddled here, so, plainly:

• Resizing keeps the shape and changes the pixel count. Circles stay circles.
• Stretching changes the shape. Circles become ovals, faces get wide, and everyone can tell.
• Cropping changes the shape by removing edges. Nothing distorts, but you lose content.

If your source is 4:3 and the slot wants 16:9, you need to crop, not stretch. Resizing cannot change an image's shape without lying about it.

The ratios worth knowing, with a width to type and the height the lock will fill in for you:

Resizing in cm, mm or inches: where DPI comes in

Every guide on this topic covers inches. Almost none of them cover centimetres, which is what most of the world's forms are actually written in, and the tool pages that do handle cm tend not to explain what is happening.

So: an image has no physical size. A 600 pixel wide photo is 15.9 cm across at 96 DPI and 5.1 cm across at 300 DPI, and it is the same photo, the same file, the same pixels. Nothing about it changed except the number you divided by.

DPI is the exchange rate between pixels and the physical world. That is all it is. Which makes the formula simple:

• Centimetres: pixels = cm ÷ 2.54 × DPI
• Millimetres: pixels = mm ÷ 25.4 × DPI
• Inches: pixels = inches × DPI

Every tool that resizes in cm is running exactly that line of arithmetic. Here is what it produces for the sizes people actually ask for:

Which DPI to pick:

• 300 DPI for anything going to a print lab. This is the number Adobe's own image size and resolution guidance treats as the print standard, and what a photo printer expects.
• 150 DPI for a draft print, a newsletter, or something being read at arm's length.
• 96 DPI for screens. This is what a CSS pixel is defined as.
• 72 DPI is a legacy screen value. Harmless, still shows up in old briefs, no longer accurate to anything.

The 72 DPI lie in most browser resizers

Here is something I only learned by building one of these, and it is the reason your carefully measured 5 cm photo sometimes prints at 20 cm.

A browser canvas encodes pixels and nothing else. When it writes a JPEG, it writes the JFIF default density: 72 DPI, regardless of what you typed into the tool. So a resizer can do the arithmetic perfectly, hand you exactly 591 × 827 pixels for your 5 × 7 cm print, and still ship a file whose own metadata claims it is 8.2 inches wide.

Then you drop it into Word, or a print dialog, or Photoshop, and the software believes the tag over your intentions.

Fixing this means writing the DPI into the file itself, which is a different job per format:

• PNG stores it in a pHYs chunk, in pixels per metre, so 300 DPI is written as 11811. It is a documented part of the PNG chunk specification.
• JPEG stores it in the JFIF APP0 header as a units flag plus two 16-bit densities.
• WebP and AVIF have nowhere standard to put it at all. The pixels are the only guarantee you get.

Our resizer writes the DPI you choose into the PNG or JPEG it hands back, and tells you on the result screen when you have picked a format that cannot carry it. That is not a headline feature, it is just the difference between the number being real and the number being decoration.

Formats change the answer

Resizing is supposed to change the dimensions and nothing else. In practice, format is where free online tools quietly break that promise.

The PNG one is the trap that costs people the most. A transparent logo resized by a tool that silently outputs JPEG arrives with a white box baked in behind it, and you find out when you drop it onto a coloured header. If your file came off a website and you are not sure what it even is, our piece on WebP files covers why your download is probably not the JPEG you assumed.

A checklist that gets it right first time

How to do it in our tool

Since this is our blog, the honest pitch, kept short.

1. Drop the image in

   JPG, PNG, WebP, AVIF or a still GIF, up to 25 MB. The fields fill in with the image's own dimensions, so a smaller version is one edit away.

2. Pick your unit, then type one side

   Pixels, cm, mm or inches. Switch units at any time and the same image is re-described rather than re-converted, so your 5 cm stays exactly 5 cm when you flip to inches and back. With the ratio locked, the other side fills itself in.

3. Set a DPI if you are printing

   The control only appears when you are working in a physical unit, because for pixels it does nothing. The pixel result is shown under the fields as you type, so the conversion is never hidden from you.

4. Resize and check

   Before and after, side by side, at the same display size. Then download.

Three things about it are relevant to everything above: it steps down in halves rather than one jump, it writes your DPI into the PNG or JPEG, and it runs entirely in your browser, so the passport photo never touches a server.

When a browser tool is the wrong answer

Worth saying, since the goal is to be useful rather than to win every case.

A whole folder at once. Ours does one image at a time. For bulk work, ImageMagick's mogrify -resize over a directory, or XnConvert if you would rather click, is genuinely the right tool. A bulk image resizer is on our list, and it is not built yet.

RAW files from a camera. A browser cannot decode them. Export a JPEG from your editor first.

Upscaling that has to actually work. Ordinary interpolation cannot invent detail. If you truly need a small image made large, that is a job for a machine-learning upscaler, and it is a different product to this one.

Files over 25 MB. That is our ceiling, and it is where a full-resolution decode starts being a coin flip on mid-range hardware.

FAQ