Resize image to exact pixel dimensions

Form portals publish pixel boxes — 200 × 230, 275 × 354, 350 × 350 — and a photo that does not match exactly is rejected by a dimension check that never even looks at the picture.

Distortion is the usual failure: stretching a 3:2 camera photo into a square makes faces look wrong. Choosing crop-to-fill or pad-on-white keeps proportions honest.

A resolution cap is also the cheapest way to make a file small: halving both dimensions cuts pixel count to a quarter.

Portals specify pixel boxes, and pixel boxes have a shape. Forcing a 4:3 phone photograph into a 3:4 portrait slot by stretching produces a visibly distorted face, which is the single most common reason an otherwise-correct photograph is flagged for manual review.

Cropping to the required ratio is the fix, and doing it deliberately — deciding what stays in frame — beats letting an algorithm guess. Our cropper shows the region before it is applied.

Resizing is also the honest way to reach a byte limit: halving width and height quarters the pixel count, while squeezing JPEG quality damages the whole image rather than just its dimensions.

This tool exists for images handled in a hurry: no queue, no account, no upload, and a result you can verify on the spot. The explanation below is the same one we would give a colleague who asked how it works.

Photographs from phones carry more metadata than most people realise — capture timestamp, camera model, the orientation tag that decides whether the picture displays upright, and often GPS coordinates precise to a few metres. Because every operation on this site writes a fresh file, that metadata does not survive by default. For a photograph of a marksheet or a bank statement, that is a privacy gain; for an archival photograph, note the date before you process it.

On a phone, memory is the real constraint rather than any size limit. A 12-megapixel photograph is about 36 MB once decoded into pixels, so compiling a batch of twenty and holding every result in memory at once will get a mobile browser killed well before it runs out of storage. Process batches of ten to fifteen on a phone; on a laptop the same job is unremarkable.

Accepted inputs are JPEG, PNG, WebP, AVIF, HEIC, GIF and BMP images up to 50 MB each. SVG, HTML and other script-bearing formats are refused outright rather than sanitised, because a file that can execute code has no business being re-encoded — and an upload field that accepts one is a security hole rather than a feature. Several files can be queued where the workbench supports it. Batch, page and memory limits apply; check every output.

Decoding uses the browser's native codecs, then drawing happens on an OffscreenCanvas. Downscaling is done in progressive halving steps rather than one big jump, because a single large downscale with bilinear filtering produces aliasing on fine detail such as text and fabric patterns. Upscaling is deliberately capped, since interpolating new pixels cannot recover detail that was never captured — a 100 px thumbnail enlarged to 275 px will always look soft. Resampling uses progressive halving where the scale factor is large, because repeated 50% reductions avoid the aliasing that a single large downscale produces — thin lines stay lines instead of disappearing or turning into noise. Upscaling is permitted but labelled, since it cannot invent detail. EXIF orientation is applied before resizing so portrait photographs are not resized as landscape, and the output is written with the dimensions you asked for rather than a rounding of them. The browser resamples the decoded pixels to your chosen dimensions. Upscaling creates interpolated pixels rather than recovering original detail; for important text or faces, start from a sufficiently sharp source and inspect the output.