How to resize images without quality loss

“Without quality loss” is asymmetric. Downscaling — making an image smaller — loses information by definition (you have fewer pixels than the source), but the loss is usually invisible if you use a good algorithm. Upscaling — making it larger — invents detail that wasn’t there, and the result alwayslooks softer than a native-resolution source. This guide explains which workflows preserve visible quality and which don’t.

Downscaling: mostly safe

If your source is 3000×2000 pixels and you need 600×400 for the web, you’re throwing away 96% of the pixels. As long as the downscaling algorithm averages the discarded pixels into the kept ones (rather than just sampling every Nth pixel), the result looks correct.

Modern browsers, Photoshop, and dedicated tools use bilinear or bicubic interpolation by default. For aggressive downscales (> 4× reduction), they chain multiple passes to avoid aliasing.

When downscaling goes wrong: nearest-neighbour sampling (which preserves pixel-art but produces jagged photographs) or single-pass downscaling at extreme ratios (which causes moire patterns). Almost no consumer tool uses nearest-neighbour by default; you’d have to explicitly ask for it.

Upscaling: always loses

A 100×100 pixel image has 10,000 pieces of information. Upscaling it to 400×400 produces 160,000 pixels — 150,000 of which the algorithm invented by interpolating between neighbours. The result is mathematically a guess.

Three flavours of upscale:

• Bilinear / bicubic. Standard interpolation. Soft, slightly blurry results. The default when you change <img> size in CSS.
• Lanczos. Sharper than bicubic, preserves edges better. Some tools default to it for 2× upscales.
• AI upscaling.Topaz Gigapixel, Adobe’s Super Resolution, ESRGAN-based tools. Trained on millions of high-resolution examples; hallucinate plausible detail. The results look better than interpolation but aren’t actually accurate — the “detail” is invented.

Practical rule: never upscale a final asset. Find a higher-resolution source. If the source genuinely doesn’t exist (an old photograph, a tiny logo), AI upscaling is the best of bad options.

Format affects visible quality

Even with perfect resizing, the format you save in determines what survives. See our PNG vs JPG vs WebP guide for the full breakdown; the short version:

• PNG — lossless. Resizing then saving as PNG preserves the resized image exactly. Use for logos, illustrations, screenshots with sharp text.
• JPEG @ 90%— visually indistinguishable from PNG for photographs at typical viewing sizes. Quality drops aren’t about the resize, they’re about the JPEG encoding.
• WebP @ 80% — 25-35% smaller than JPEG at equivalent quality. The web default for photographs since 2020.
• GIF — limited to 256 colours; resized GIFs of photographs look posterised. Convert to PNG or WebP instead.

The protect-the-source workflow

Once you resize-and-save, you can’t recover the original detail. So:

1. Archive the source. Original-resolution PNG or RAW. Tag/folder it so future-you can find it.
2. Generate derivatives. Web sizes from the source, not from a previously-resized copy. Each round of resize-and-save accumulates compression artifacts; starting fresh from the source avoids that.
3. Generate the sizes you actually need.Common: @1× for traditional displays, @2× for Retina, @3× for high-end phones. Serve via <img srcset> or <picture>.
4. Don’t re-edit a JPEG. Each save drops more information. If you need to colour-correct after the fact, do it on the source, then re-export.

Browser-side vs desktop-side resizing

Modern browsers do high-quality resizing in Canvas2D — what our image resize tool uses. Results are visually identical to Photoshop’s bilinear/bicubic for most cases. For aggressive downscales (> 8× reduction), Photoshop’s “Image Size” with bicubic-sharper still has a slight edge in preserving fine detail.

For batch processing or unusual interpolation needs, desktop tools (ImageMagick, GraphicsMagick, oxipng) give finer control than browser tools. Most workflows don’t need this control; the browser is enough.

Common mistakes

• Resizing in CSS instead of in code.A 4000×3000 image served at width=400 in CSS is still 4000×3000 bytes over the wire. The browser can resize, but the network already paid. Resize at export time, not at display time.
• Forgetting Retina. A 200×200 image on a @2× display renders blurry. Export at 400×400, display as 200×200 CSS pixels.
• Cropping by upscaling. If you crop into 25% of an image, you have a quarter-resolution image back. Upscaling it to the original dimensions just enlarges the artifacts. Crop first, then accept the lower resolution as the new ceiling.

For the live tool, see our browser-only image resizer and the companion image compressor. Both run entirely in your browser — files don’t leave the page.

Sources: ITU-R BT.601 (downsampling filter recommendations); WebP encoding paper (Google, 2010); Mozilla Developer Network “Responsive images” guide.