Resize an image by pixels, by percentage, or to fit a box

The six modes, and which question each one answers

Resizing sounds like one operation and is really six, distinguished by what you already know. Picking the wrong one is how an avatar ends up with somebody's forehead cropped off.

Longest edge is the one to reach for when a service states a single number — "images must be no more than 1600 pixels" — because it works whether the photograph is portrait or landscape. A 4032 × 3024 phone photo capped at 1600 becomes 1600 × 1200, a scale of 0.397, which is 1.92 megapixels instead of twelve.

Fit and fill are the pair that get confused. Fit scales until the whole image is inside the box, so one side usually ends up smaller than the box and nothing is lost. Fill scales until the box is covered and then centre-crops the overflow, so the output is exactly the box and pixels are gone. The same 4032 × 3024 photo filled into a 512 × 512 avatar becomes 512 × 512 with a 3024 × 3024 region taken from the middle — a quarter of the frame discarded, which is correct for an avatar and wrong for a document.

Why downsampling in one jump looks bad

Ask a browser to draw a 4032-pixel-wide image into a 400-pixel-wide canvas and, depending on the implementation, it may sample roughly one source pixel for each destination pixel and discard the other hundred. The result is aliasing: fine detail turns into moiré, diagonal edges turn into staircases, and the photograph acquires a crunchy, over-sharpened look that no amount of quality setting will fix, because the damage happened before the encoder ran.

The fix is old and cheap. Halve the image repeatedly until the next step would overshoot, then do the final step. Each halving averages four pixels into one, so by the time the image reaches the target size every source pixel has contributed to the result. This tool does that, and it costs about a millisecond.

It is also why the output of a resize here is usually slightly softer than a naive resize and considerably better looking. Softness from correct averaging is real information; crispness from aliasing is an artefact.

Avatar and profile sizes, and why they are smaller than you think

Most platforms ask for an upload far larger than anything they ever display, then re-encode it on their own servers. Knowing the displayed size is what stops you spending four megabytes on a picture that will be drawn at 98 pixels.

The practical summary: one square image at 512 × 512 covers essentially every avatar slot on this list. Anything larger is re-encoded on the other side anyway, and anything much smaller looks soft on a high-density screen. Use the fill mode with a 512 × 512 box, check that the crop kept your face rather than your shoulder, and be done.

Circular masks are worth one thought. Every platform in the table above except Slack and GitHub crops an avatar to a circle, which removes the corners — so anything important needs to sit inside the inscribed circle, not the square. Text along the bottom edge of a logo disappears entirely.

Enlarging, and what it can and cannot do

This tool will enlarge an image if you switch it on, and the receipt will say that it did. Interpolation invents intermediate pixels from the ones around them; it does not recover detail, because the detail was never recorded. Doubling a 400-pixel image produces an 800-pixel image that carries exactly as much information as the 400-pixel one and looks softer at any given viewing size.

The machine-learning upscalers that genuinely add apparent detail do so by inventing plausible detail — which is fine for a wallpaper and disqualifying for anything used as evidence, for identification, or for a document. Nothing on this site does that, and nothing on this site pretends the question does not exist.

If the requirement is a print size rather than a pixel size, the arithmetic is simpler than it looks: divide pixels by the print resolution. A 1600-pixel image at 300 dots per inch is 5.3 inches across; at 150 dots per inch, which is fine for anything read at arm's length, it is 10.7 inches. The EXIF resolution field has nothing to do with this and changing it changes nothing about the picture.

Transparency, rotation and metadata

PNG and WebP both carry an alpha channel, and resizing preserves it. JPEG cannot store transparency at all, so choosing JPEG flattens the image onto white — the tool checks the source first and only raises the point when there really are transparent pixels. If transparency matters and file size matters, WebP is the format that does both.

Rotation is handled before anything else. A phone stores most photographs in landscape with an EXIF tag saying which way to turn them, and a canvas ignores that tag unless asked. This tool asks, so the rotation is baked into the pixels and the output needs no tag — which is also why the resized file displays the right way up in software that ignores EXIF entirely.

Because the output is encoded from pixels, no metadata survives: no location, no camera, no serial numbers, no XMP, no C2PA. That is a side effect rather than the purpose. If the point is to remove the metadata and keep the picture untouched, the metadata tool does it without re-encoding anything, and the compressor is the right page when a file-size ceiling rather than a pixel size is what you are up against.