Image Resizer

Why one-step downscaling looks bad

When a browser draws a large image into a much smaller space in a single operation, it samples a limited number of source pixels and ignores the rest. Detail that fell between the samples is not averaged in, it is discarded, and the result is aliasing: jagged diagonals, shimmering on fine textures, and text that turns into noise. This is why an image scaled down with a plain width attribute usually looks worse than the same image scaled by an image editor.

The fix used here is to halve the image repeatedly and only take the final small step at the end. Each halving averages groups of four pixels, so by the time the target size is reached every output pixel is derived from the whole area it represents rather than from one arbitrary sample within it. It is the same principle as mipmapping in graphics, and on a large reduction the difference is not subtle.

Dedicated tools go further with Lanczos or similar filters, which weigh a wider neighbourhood and preserve a little more apparent sharpness. Successive halving is close enough that the gap is hard to see on photographs, and it runs fast enough to preview instantly on a phone.

Choosing the target size

Size for where the image will be displayed, then account for pixel density. A photo shown 800 CSS pixels wide on a page needs to be about 1600 pixels to look sharp on a modern phone or laptop, which have two device pixels per CSS pixel. Beyond 2x there is very little visible return and a substantial file-size cost.

For a page serving many devices, the better answer is several sizes and a srcset attribute, letting the browser pick. Common widths of 640, 960, 1280 and 1920 cover most layouts. For an email, keep to 600 pixels or so. For a document or a slide, match the placed size at 2x.

Never upscale to hit a target. Enlarging invents pixels that were not photographed; it makes a soft image larger and softer, and it makes the file bigger for no gain. If something needs to be larger than the source, the source is what has to change.

The ceiling, and why it exists

Files are accepted up to 30 MB, and images up to roughly 16.7 million pixels - about 4000 by 4000, or any other shape with the same total area.

That limit is the browser's canvas, not an arbitrary policy. Safari on iOS in particular caps the area a canvas may cover, and the failure mode above it is the worst kind: no error, no exception, just a blank white image handed back as though everything worked. Rather than let that happen, anything over the limit is refused with an explanation. If you have a 50-megapixel raw export to shrink, a desktop image editor is the right tool.

The same limit is why batches are processed one image at a time rather than in parallel. A decoded image occupies width times height times four bytes in memory regardless of how small the compressed file was, so several large ones at once is what makes a phone browser drop the tab.

Resize, crop, or compress

These solve different problems and are often confused when the real goal is a smaller file.

Resizing changes how many pixels there are and is by far the most effective lever on file size, because it is quadratic - halving the width and height quarters the pixel count. It changes what is visible at full size but keeps the whole frame.

Cropping changes what is in the frame. It reduces pixels too, but it is a compositional decision rather than a technical one, and it cannot be undone.

Compressing changes how precisely the existing pixels are stored, which is the quality setting in the converter. It leaves the dimensions alone and trades fidelity for size.

For a photo that is too heavy for a web page, the order that works is resize to the displayed size first, then encode as WebP or JPG at a sensible quality. Doing only the second usually leaves most of the saving on the table.

Why downscaling needs a filter at all

Reducing an image means answering a question for every output pixel: what colour represents this region of the original. Taking the nearest source pixel and ignoring its neighbours is the cheapest answer and the worst one, because detail that fell between the sampled points is discarded rather than averaged, and the discarded detail reappears as a pattern that was never in the photograph.

That is aliasing, and it is the same phenomenon as the wagon wheel that appears to spin backwards in a film. Sampling at a lower rate than the detail requires does not lose the detail quietly; it folds it back into the image as a false, lower-frequency pattern. Fine textures shimmer, diagonal lines step, and small text turns into noise.

The fix is to average over the whole area each output pixel represents, and different filters weigh that average differently. Box averaging is simple and slightly soft; Lanczos weighs a wider neighbourhood with a sinc-based curve and keeps more apparent sharpness at the cost of faint ringing near hard edges. Successive halving, used here, gets most of the way there at a fraction of the cost.

Dimensions, aspect ratio and cropping

Resizing preserves the whole frame and changes how many pixels describe it. Cropping changes the frame. Confusing the two produces the distorted images you see on badly built sites, where a wide photograph has been squeezed into a square container by setting both dimensions independently.

Where a layout demands a fixed shape, crop deliberately rather than stretching. CSS object-fit with cover does this in the browser and is fine for decorative images; for anything where the subject matters, cropping in advance gives control over what stays in frame. Automatic centre-cropping reliably decapitates people in group photos.

Art direction is the case where one crop is not enough: a wide hero image that works on a desktop often needs a tighter portrait crop on a phone, not merely a smaller version of the same frame. That is what the picture element with media conditions is for, as distinct from srcset, which serves the same crop at different sizes.

Image weight and what it costs a page

Images are usually the largest thing a page downloads, and the largest contentful paint - one of the metrics Google reports in Core Web Vitals - is very often an image. Every unnecessary kilobyte in that one file delays the moment the page looks loaded.

A workable budget is to keep the hero image under about 200 KB and everything below the fold much smaller, which is achievable at ordinary quality settings once the dimensions are right. Serving a 3 MB photograph and letting CSS scale it down is the single most common performance problem on content sites, and it costs the visitor their data allowance as well as their time.

Layout stability is the other half. An image with no declared width and height reserves no space, so the text below it jumps when the image arrives. Setting both attributes, or an aspect-ratio in CSS, is a one-line change that removes an entire category of visible defect.

Resizing many images at once

For a handful of files a browser tool is the fastest route. Past a few dozen, or as part of a build, a scripted tool is better: ImageMagick's mogrify -resize 1600x -quality 82 *.jpg handles a directory in one command, and sharp, libvips or Pillow do the same inside a Node or Python pipeline with far lower memory use than their reputation suggests.

Two habits prevent the usual accidents. Work on copies, since mogrify overwrites in place by default and there is no undo. And use a width-only constraint such as 1600x rather than fixed dimensions, so portrait and landscape images are both handled without distortion.

For a site that receives user uploads, resizing should happen once on ingest rather than on every request, with the original kept if you may need other sizes later. Deriving sizes on demand through an image CDN is the other reasonable architecture; doing it in the page with CSS is not, because the full file is downloaded either way.

Upscaling, and what AI tools change

Enlarging an image cannot recover detail that was never captured. Classical interpolation - bilinear, bicubic, Lanczos - makes a smooth larger image from the same information, which looks soft because it is soft. That is not a deficiency in the algorithm; the information is genuinely absent.

Machine-learning upscalers produce something sharper by inventing plausible detail based on what they have seen before. For a wallpaper or a print of a holiday photo that is often exactly what you want. For anything evidentiary - a document scan, a product photograph a customer will rely on, an image in a news report - it is a serious problem, because the added detail is a guess presented with the same confidence as the real pixels.

The dependable rule stays the same: fix the source. Re-export from the original file, re-scan at a higher resolution, or ask for the asset at the size you need. Everything else is a repair with invented material.