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.

Worked example: a hero image for a Retina laptop

Target slot in the design: 1200 × 600 CSS pixels. Source: a 24-megapixel DSLR shot, 6000 × 4000 pixels, sRGB JPEG.

• Pick output dimensions. For @2× Retina, export 2400 × 1200 device pixels. For phones with @3× DPR, export 3600 × 1800. Use <picture> with srcset to serve the right one.
• Crop, then resample. Crop the 6000 × 4000 to a 2:1 region (e.g. 6000 × 3000), then resample down to 2400 × 1200 using Lanczos3 in ImageMagick: magick input.jpg -filter Lanczos -resize 2400x1200^ -gravity center -extent 2400x1200 [email protected].
• Encode WebP at quality 80. cwebp -q 80 [email protected] -o [email protected]. Expected file size: ~85-130 KB at this resolution. Equivalent JPEG q=85 would be ~180-220 KB.
• Add an AVIF variant for browsers that support it. avifenc --speed 6 -q 60 [email protected] [email protected] → another 25-40% smaller than WebP.
• Total payload: ~95 KB AVIF for modern browsers, ~110 KB WebP fallback, ~200 KB JPEG legacy fallback. Compared to serving the unresized 6 MB DSLR original: 60× smaller.

Common mistakes

• Re-saving JPEG after every edit. Each JPEG encode is lossy. After 5-10 round-trips the artifacts become visible. Always start edits from the original (PNG/PSD/RAW) and treat the JPEG only as a final export.
• Using nearest-neighbour by accident.CSS image-rendering: pixelatedor PowerPoint “Insert picture, do not resample” both bypass the smooth scaler. Pixel art needs nearest-neighbour; photographs need it never.
• Forgetting the alpha channel.Resizing a PNG with transparency using a non-premultiplied algorithm produces dark fringes at the alpha edges. Premultiply before resampling, then un-premultiply. ImageMagick’s -alpha set handles this when given the right flags.
• Trusting the browser’simageSmoothingQuality="high"uniformly. Safari, Firefox, and Chrome implement this differently. For pixel-perfect work, do the downsampling server-side (sharp, ImageMagick) and ship the finished asset.
• Treating “Photoshop bicubic sharper” as universally best. Bicubic sharper introduces ringing artifacts at high-contrast edges. For text, use Lanczos. For photographs at moderate downscales, bilinear with a slight sharpen is often visually equivalent and much faster.

Edge cases

• SVG.Vector graphics don’t need resampling — they re-render at any size losslessly. The only resize concern is hinting for sub-pixel positioning and ensuring stroke widths don’t collapse below 1px at the target size.
• Animated GIF/WebP. Resampling per-frame with no temporal coherence introduces flicker between frames. Use ffmpeg with a temporal filter, or convert to a modern animated format (WebP, AVIF, AV1).
• HDR images. 10-bit and 12-bit PQ/HLG-encoded content needs HDR-aware resamplers; a bog-standard 8-bit resampler crushes highlights and shadows. OpenColorIO and ACES workflows handle this.
• Print at >300 PPI on uncoated stock.Ink dot gain on uncoated paper saturates around 250 PPI; resampling source to 600 PPI is wasted bytes. Match the press capability, not the file metadata.

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