Resize an image

How it works

Resizing an image for the web is a question of pixel dimensions and nothing else. A photo that is 4032×3024 holds 12.2 megapixels, and that grid is the whole of its size on screen. The DPI or PPI number stored alongside it (in a JPEG's JFIF header, in a PNG's pHYs chunk) is inert metadata that no browser consults when laying out a page. Changing it from 72 to 300 rewrites a handful of bytes and alters nothing you can see.

That number only acquires meaning when software maps pixels onto a physical surface: a printer, or a page-layout application deciding how many inches wide to place the image. When a form asks for a 300 DPI photo it is really asking for enough pixels to cover the printed size it has in mind, and that is a property of the original capture rather than of a field you can edit.

Downscaling keeps, enlarging invents

Downscaling is the case that works well. Averaging many source pixels into one output pixel discards detail you genuinely had, but everything that remains is real, and the file shrinks sharply because there is less data to store — halving both dimensions removes three quarters of the pixels.

Enlarging is the opposite and it cannot work the same way. There is no detail hiding inside a 400×300 image waiting to be released; a resampler asked for 1600×1200 must invent sixteen output pixels for every one it was given, and it invents them by interpolating between neighbours. The result is a larger, softer copy of the same picture. Enlarging is sometimes the right move when a system enforces a minimum dimension, but no resizer recovers information that was never captured.

Bilinear moiré versus Lanczos3

How the pixels are combined matters more than most people expect. Most in-browser resizers take the quick approach and draw the image into a canvas at a smaller size, relying on the browser's built-in filtering. That filtering is fast, roughly bilinear, and prone to aliasing on fine detail: small text turns to mush, and brick walls, railings and striped shirts shimmer with moiré.

This tool runs a Lanczos3 filter compiled to WebAssembly instead. It samples a wider neighbourhood through a windowed sinc kernel, which holds edge contrast together and suppresses the interference patterns that appear when a regular pattern is sampled down onto a coarser grid. It costs a few milliseconds and is visibly better on anything containing text or repeating structure.

The round trip through pixels

Resizing is never a crop-and-copy operation on the existing file: the image is fully decoded to raw pixels, resampled, and then encoded again from scratch. For PNG that round trip is exact, because PNG is lossless. For JPEG it is not. Every save quantises the image again, so repeatedly resizing a JPEG accumulates generation loss much like repeatedly photocopying a page, with blocking and colour bleeding around hard edges showing up first.

JPEG also has no alpha channel, so a transparent source is composited onto white before encoding, and that happens before the resample rather than after it: a resampler blends colour and transparency independently, and mixing in the arbitrary colour stored under fully-transparent pixels would leave a dark fringe along every soft edge. Work from the original where you can rather than from something that has already been through a resizer.

Formats without an encoder here

GIF and BMP are accepted as input but come back as PNG, because this suite ships no GIF or BMP encoder; for an animated GIF that also means you get the first frame only. Decoding, resampling and encoding all happen in a Web Worker on your own machine.