How to Resize an Image Without Losing Quality

Downscale: mostly safe

Going from a 4000 px source to 1200 px is visually lossless on screen — there's still more detail in the source than the display can show.

Just resize once. Resizing in multiple small steps compounds tiny rounding errors and softens the image.

The interpolation method matters more than people realise. Lanczos and bicubic produce sharper downscales than bilinear or nearest-neighbor. Most modern image tools default to Lanczos for downscaling, which is the right choice for photos. If your output looks soft, check whether the tool quietly switched to a faster but lower-quality method.

Below a certain ratio, aliasing becomes a problem. Downscaling by more than 4x in a single pass can produce moire patterns on fine textures (fabrics, brick walls, distant foliage). Most encoders add a pre-filter to suppress this, but very aggressive downscales sometimes need a manual blur step beforehand. If you see strange repeating patterns after resizing, that's what happened.

Upscale: be realistic

Doubling 600 px to 1200 px works for moderate use. Quadrupling almost always softens. Beyond 2x, use a model-based upscaler — our Image Enhancer's 2x upscale mode is tuned for photos.

Traditional bicubic upscaling cannot invent detail that isn't in the source. It can only interpolate between existing pixels, which produces a smoothly blurred version of the original at a higher resolution. The pixels are there but the information density isn't.

Neural upscalers (ESRGAN, Real-ESRGAN, SwinIR, and similar models) are trained on pairs of low- and high-resolution images. They learn what high-resolution photos typically look like and hallucinate plausible detail at the higher resolution. The result looks sharper but is fundamentally a guess. For photos this works well. For text, line art, or anything with exact geometry, neural upscalers often invent the wrong shape.

Aspect ratio gotchas

Locking aspect ratio keeps proportions. Unlocking stretches the photo to fit exact dimensions, which usually looks wrong. If you need exact target dimensions without distortion, crop first.

Common forced ratios trip people up. A 1080x1080 Instagram post from a 4032x3024 source needs cropping, not stretching. A 1200x630 Open Graph image from a 1920x1080 source also needs cropping. The cleanest workflow is to crop to the target aspect ratio first, then resize to the target pixel dimensions — that order keeps the resize purely scalar and avoids any distortion.

Cover versus contain. If you're using CSS object-fit, cover crops the image to fill the container and contain shrinks it to fit. For server-side resizing the equivalents are smart-crop (cover) and letterbox (contain). Match the server-side resize to the CSS layout to avoid double-processing the image.

Step-by-step

Using our free resizer:

• Open the Image Resizer.
• Drop a photo.
• Type the width — height auto-fills with aspect ratio locked.
• Click Resize image.
• Click Download.

Practical target sizes

Web hero images: 1600-2000 px on the long edge covers retina screens up to about 13 inches. Going larger wastes bandwidth without visible benefit.

Blog body images: 1200 px wide is enough for any common layout, with 2x retina rendering down to about 600 CSS pixels.

Email signatures and embedded images: 600 px wide is the safe ceiling. Many email clients cap rendered widths anyway.

Social media: Instagram 1080x1080 for square, 1080x1350 for portrait, 1080x1920 for stories. Twitter/X timeline images render best at 1600x900. LinkedIn cover images need 1584x396.

Print: at 300 DPI, a 4x6 print needs 1200x1800, an 8x10 needs 2400x3000, and a 16x20 needs 4800x6000. Below those, the print will look soft to anyone holding it close.

When resizing makes things worse

Screenshots of UI with pixel-perfect text. Resizing to a non-integer ratio (say, 0.83x) blurs every character edge. Either keep the original size or scale to integer ratios (0.5x, 0.25x). For browser screenshots, take them at the final display size from the start.

Icons and logos that came as raster. Resizing a 32x32 favicon up to 256x256 produces a soft mess no matter what algorithm you use. The right fix is to find or recreate the vector version, then export at the target size.

Already-compressed JPGs that have visible artifacts. Resizing won't remove the artifacts; it will just move them around and add a soft layer on top. Re-export from the original source if you can.

Photos that have been through multiple platforms (uploaded to chat, screenshotted, saved again). Each round added some loss. By the time you're resizing the result, you're polishing damage. Track down the original.

Faces that have been through beauty filters with feature reshaping. The reshaped pixels don't line up with the underlying anatomy, so any resize amplifies the unnatural look. The fix isn't a different resize algorithm; it's going back to the unfiltered version.

Performance considerations for the web

Serve images at the size they'll actually display. A 4000 px hero image on a 1200 px container wastes 90% of the downloaded bytes. The HTML srcset and sizes attributes let you ship multiple sizes and let the browser pick the right one based on the actual viewport and pixel density.

Lazy loading via the loading='lazy' attribute defers off-screen images until the user scrolls near them. Combined with appropriate sizes, this can cut initial page weight by 60-80% on image-heavy pages.

For responsive designs, generate three to five sizes per image: roughly 600, 1200, 2000, and 2800 px on the long edge. The browser picks the smallest size that meets the display requirement, so most users on most devices download well under the full-size version.

Why the resampling algorithm matters

Going from 4000 pixels wide to 800 means one output pixel for every twenty-five in the source. Something has to decide what each output pixel becomes, and different algorithms decide differently enough to be visible.

Nearest neighbour picks one source pixel and discards the other twenty-four. It is the fastest and the worst, producing hard aliasing on any fine detail. Bilinear consults the four nearest pixels regardless of the scale factor, so at a 5x reduction it still ignores twenty-one of the twenty-five. Bicubic consults sixteen and weights them with a smoother curve, which is better but has the same structural problem at large reductions.

The honest answer for a large downscale is to average every contributing pixel, which is what an area or box filter does. That eliminates aliasing entirely because no source pixel is skipped.

Stepped halving, and why it works

The practical technique is to reduce in repeated halving steps rather than one jump: 4000 to 2000, then 2000 to 1000, then 1000 to 800.

At each halving the scale factor is small, so a four-nearest-pixel filter is consulting exactly the pixels that matter. Every source pixel contributes to the stage below it, and by the final step all four thousand original columns have influenced the result.

The cost is a few extra intermediate operations, which is negligible. The benefit shows immediately on patterned content — brickwork stays as brickwork rather than becoming a shimmering interference pattern, and small text stays legible rather than breaking up into fragments.

The order of operations

Resize, then sharpen, then compress. Each of these steps is destructive, and this sequence minimises how much each one has to destroy.

Sharpening before resizing is the common mistake. It raises contrast at edges, and the downscale then averages those exaggerated edges together, baking halos into the result that cannot be removed afterwards.

Compressing before resizing is worse. The encoder spends bits describing four million pixels, you discard 95 percent of them, and the compression artefacts themselves get resampled into a fine texture that the next encode has to describe as though it were real detail. One generation of loss becomes two, and the file is larger at the end of it.

Aliasing, and what it looks like

Aliasing is what happens when a pattern finer than the sampling grid gets sampled anyway. The result is a false pattern that was never in the original — moiré on fabric, shimmer on roof tiles, jagged stepping on diagonal lines.

It is most visible on regular repeating detail: brick, weave, railings, halftone printing, and small text. It is least visible on smooth content like skies and skin, which is why a portrait can survive a careless resize and an architectural photo cannot.

Once it is in the file it cannot be removed, because the false pattern is now genuine image data. The only fix is to go back to the original and resize it properly.

Retina and high-density displays

A high-density screen packs two or three device pixels into each CSS pixel, so an image displayed at 600 CSS pixels wide is drawn using 1200 or 1800 device pixels. Supplying only 600 means the browser upscales, and it will look soft on exactly the screens people notice softness on.

The usual approach is to supply two versions and let the browser choose with srcset, so a phone downloads a phone-sized file and a high-density laptop downloads the larger one.

Doubling is enough. Supplying a 3x asset costs four times the bytes of a 1x for a difference almost nobody can identify, and on a slow connection that trade is clearly bad.

Resizing images that contain text

Text is the hardest content to downscale, because letterforms are precisely the fine high-contrast detail that resampling damages first. Below roughly 60 percent of original size, small interface text becomes unreliable regardless of the algorithm.

If a screenshot has to be readable, crop rather than scale. A tight crop of the relevant region at full resolution communicates better than the whole screen shrunk to fit, and it is usually a smaller file as well.

If it must be scaled, use stepped halving, add a light sharpening pass, and then check the result at the size it will actually be displayed rather than zoomed in. A screenshot that looks fine at 100 percent zoom can be illegible in context.

Frequently asked questions