Does resizing a PNG lose quality, or only a JPG?

Both, and for different reasons. Making a picture smaller discards pixels whatever the format, so a PNG taken from 4000px to 400px has lost the same detail a JPG would have. The difference is the second loss. A JPG is re-compressed on the way out, so it picks up a fresh round of encoding damage on top; a PNG is not, so it records the downscaled picture exactly. That makes PNG the better choice when a file is going to be resized several times over its life, and the worse choice for a photograph you are shipping once, because it will be several times the size.

If I resize the same photo twice, does the damage add up?

Yes, and it adds up faster than people expect, because each pass is working from the last result rather than from the original. Going 4000 to 2000 to 1000 is measurably worse than going 4000 to 1000 in one move: the intermediate got rounded to whole pixels and re-encoded, and the second pass inherits all of that. The fix is to keep the original and always resize from it. That is why this tool re-renders every file from its own decoded original whenever you touch a setting, instead of resizing the thing it produced a moment ago.

Can an AI upscaler put the detail back?

It can put something back, and it is not the detail you lost. An upscaling model has learned what skin, brick and foliage usually look like, so it invents plausible texture where the file has none. On a landscape that often looks better than a blurry enlargement. On a face, a licence plate or a document it invents features that were never there, confidently. So it is a good tool for making a picture look acceptable and a bad tool for recovering information, and the difference matters enormously if anyone is going to rely on what the picture shows.

Does DPI matter when I am resizing for the web?

No. DPI is a number stored in the file that says how large to print it, and screens ignore it completely. A 1200×800 image at 72 DPI and the same image at 300 DPI are the same pixels and the same file size, and a browser draws them identically. The 72 DPI rule is a leftover from 1980s Mac displays and it has been meaningless for web work for about twenty years. What matters on screen is the pixel dimensions, which is what a resizer changes. DPI only starts to matter the moment the file goes to a printer.

Does resizing on an iPhone or in Preview lose more than doing it in a browser?

Not meaningfully. Preview, Photos, Paint and Photoshop all do the same arithmetic, and at ordinary reduction factors the results are within a rounding error of each other. The measurements below found the gaps between methods only opening up past about eight times reduction, which is thumbnail territory. What actually varies between tools is the second half of the job: what quality they re-encode the JPG at, and whether they let you see the result before committing. Those choices move the file size far more than the scaling algorithm does.

How small can a photo go before the loss is visible?

It depends entirely on how large it is drawn, not on how large the file is. A picture displayed at 600px wide on a page looks identical whether it was resized to 600px or left at 4000px, because the browser is doing the same downscale either way. The loss becomes visible the moment someone views it larger than the size you saved: opening a 600px image full screen on a laptop is a four-times enlargement and it looks soft immediately. So the rule is to save at the largest size it will be shown at, doubled if it has to survive a high-density screen, and no larger.

Does resizing an image reduce quality?

Yes on the way down, and worse on the way up. Here is how much, measured on five real files.

Free toolImage ResizerDrag a crop box on the picture, or type an exact size, and watch the real result beside it.Open the resizer

The short answer

Making an image smaller destroys information permanently. Four pixels become one, and the three that were averaged away are not written down anywhere. Nothing you do afterwards brings them back, which is why enlarging a shrunk photo gives you a bigger blurry photo rather than the original.

What is easy to miss is that the loss usually does not matter. A picture shown at 600px wide is being downscaled by the browser anyway, so saving it at 600px and saving it at 4000px look the same on the page. The damage only becomes visible when something is displayed larger than the size it was saved at. Resize for the largest size a picture will actually be seen, and the loss is real and invisible at the same time.

Three separate things get called "quality loss"

They have different causes and different fixes, and conflating them is why the answers on forums contradict each other.

Resampling loss. Fewer pixels means less information. This is unavoidable and permanent, and it is proportional to how far you shrink.

Re-encoding loss. Saving as JPG or WebP throws away more detail on top, independently of the size change. Resize a JPG and you pay both. Resize into a PNG and you pay only the first.

Resampling artefacts. A downscale done badly does more than lose detail: it creates things that were not in the picture. Fine regular patterns turn into moire, and hard edges pick up jagged staircases. This is the only one of the three that depends on which tool you used, and it is what the measurements below are about.

What I measured, and how

Five files, chosen to span what people actually resize: a phone photo, a large stock photograph, a video still, a flat-colour poster graphic and a printed card design. Each was downscaled to five widths, from a gentle reduction to a thumbnail.

Every result was compared against a reference computed the slow, correct way: an exact box filter in JavaScript that averages every source pixel falling inside each output pixel, at full floating-point precision. That reference is what a perfect downscale looks like, so the distance from it is the error the method introduced. The scores are SSIM on luma, in 8×8 windows, where 1.0000 is identical.

Two methods were compared. One pass is a single canvas drawImage with imageSmoothingQuality set to high, which is what browser-based resizers do. Then stepped, which halves the picture repeatedly and makes only the last step directly.

Chrome 151 on macOS, 10 cores, 21 August 2026. Five runs per cell. The full-precision reference is recomputed per file and per target size. Timings were taken and are not published: a GPU-backed canvas finishes its work asynchronously, so the numbers measured the call and not the resize, and a figure that does not measure what it claims to is worse than no figure.

How much a downscale costs, and when the method starts to matter

File	Reduction	SSIM, one pass	SSIM, stepped
Phone photo, 4032×3024	3.4×	0.9952	0.9952
Phone photo, 4032×3024	13.4×	0.9976	0.9982
Phone photo, 4032×3024	26.9×	0.9963	0.9981
Stock photo, 5926×3951	4.9×	0.9933	0.9914
Stock photo, 5926×3951	9.9×	0.9910	0.9941
Stock photo, 5926×3951	39.5×	0.9799	0.9961
Video still, 3840×2160	12.8×	0.9922	0.9943
Poster graphic, 1254×1254	4.2×	0.9910	0.9849
Poster graphic, 1254×1254	8.4×	0.9901	0.9858
Card design, 2321×1442	15.5×	0.9898	0.9884

The result contradicted what I expected when I started, which was that stepping always wins. It does not. Below about eight times reduction, Chrome's own filter is as good as stepping and sometimes better: on the stock photo at 4.9× it scored 0.9933 against 0.9914, so stepping there would have cost quality rather than saved it.

Past eight times the order reverses and the gap gets large. The same photograph taken down to 150px wide scores 0.9799 in one pass and 0.9961 stepped. That difference is visible rather than statistical: the single pass is dropping samples it never looked at.

And the poster graphic is the row that spoils the story. Repeated halving blurs hard edges slightly more than one good filtered pass does, so on flat artwork stepping loses, by about 0.004 to 0.006 SSIM. I tried to detect that case cheaply and could not: the photograph that gains most from stepping reads as 38% flat under the obvious flatness test, which is the same score the artwork that loses by it gets. So the tool steps on reduction factor alone, above eight times, and on flat art above that threshold it gives up a little. That is a real cost and it is written here rather than left out.

How much comes back if you enlarge it again

This is the question underneath most of the others. Each file was shrunk and then scaled straight back to its original size, and the result compared with the original. PSNR in decibels, where higher is closer and above about 40 dB is hard to tell apart by eye.

Shrunk by	Phone photo	Card design	Video still
2.5×	43.3 dB	43.6 dB	31.6 dB
3.4×	40.8 dB	38.8 dB	29.7 dB
6.7×	34.6 dB	31.0 dB	25.7 dB
13.4×	29.7 dB	26.4 dB	21.8 dB
26.9×	25.1 dB	24.0 dB	20.2 dB

Nothing here recovers. Halving a photo and putting it back costs a couple of decibels and you would struggle to see it. Shrinking by 27 times and enlarging again lands at 25 dB, which is unmistakably soft. The curve is steep and it only goes one way, so the practical advice is simply to keep the original file. A resized copy is a derived artefact, and treating it as a master costs you every time.

The ways to resize that are not this tool

None of these are worse at the arithmetic. They differ in what else they do to the file, and that is usually what decides which one to reach for.

Method	Worth knowing
Preview on macOS	Tools then Adjust Size. Fast and good, and it edits the file in place by default, so duplicate first or you have overwritten your original.
Photos on iPhone	There is no resize. Share, then Options, and choose a smaller size on export, or use Shortcuts for a real one. This is the gap most people hit.
Paint on Windows	Ctrl+W opens Resize. Perfectly serviceable, and it re-saves JPGs at a fixed quality you cannot set, which is why files sometimes come out heavier than expected.
PowerToys Image Resizer	Right-click a selection in Explorer and resize a whole folder. The best free batch option on Windows if you resize often enough to install something.
Photoshop	Image Size, with a resampling menu. Preserve Details is genuinely better on enlargements than anything a browser can do, because it is not a plain filter.
ImageMagick	`magick in.jpg -resize 1200x out.jpg`. The right answer for thousands of files or for a script, and the only one on this list you can put in a build.

The browser's advantage is not quality, it is that there is nothing to install and nothing to upload. For one photo, or a folder of them, on a machine you do not control, that is usually the whole argument.

What to do about it

Keep the original. Resize from it every time rather than from the last copy you made. This is the single thing that prevents most avoidable loss.

Resize once, to the largest size it will be shown. Doubled if it needs to survive a high-density screen. Going smaller than that saves bytes you will pay for the moment anyone opens it larger.

Do not enlarge to meet a minimum. If a platform wants 1080×1080 and your photo is 600px, pad it to the canvas instead. The picture stays sharp at its own size and the file still meets the requirement.

Check the output size before you save. Almost all the "resizing ruined my photo" cases are re-encoding, not resampling: a tool quietly saved at quality 60 and there was no way to see it had. Seeing the number before you commit is what catches that.