Does resizing an image reduce quality?

Down is fine. Up is not.

Resizing an image down discards pixels. The detail is gone permanently, but the result at its new size generally looks as good as the original did at that size, sometimes better, because downscaling averages away noise.

Resizing an image up cannot recover what was never captured. It fills the new pixels by guessing from their neighbours, and guessing produces softness, halos around edges, and a plasticky look in areas of fine texture. An enlarged image is always a worse image than one photographed at that size.

This is why a good resizer will not upscale by default, and why ours refuses to: if you ask for 1920 wide from a 640-wide source, you get 640. Blowing it up would triple the file for detail that is not there.

What "quality" means in the file, separately

There are two independent things people call quality, and conflating them is where most confusion comes from.

Dimensions are how many pixels there are. Resizing changes this.

Compression quality is how aggressively those pixels are stored. A JPEG quality setting changes this, and it is where visible artefacts, blocking, mushy edges, coloured fringes around text, come from.

You can resize an image and lose nothing perceptible while destroying it with a bad quality setting, or vice versa. They are separate decisions.

The one place they interact: after downscaling, you can usually get away with a lower quality setting than the original needed, because the compression artefacts get averaged down along with everything else.

Every resize of a JPEG re-encodes it

This is the part that surprises people. A JPEG cannot be resized without being decoded to pixels and compressed again, and that second compression is lossy whatever quality you pick. Resize the same JPEG five times at "100%" quality and it will be measurably worse than the original.

So: resize from the original once, rather than resizing the resized version. Keep the master file. If you are producing several sizes, produce all of them from the same source rather than in a chain.

PNG does not have this problem: it is lossless, so the only thing lost is the pixels you asked to remove.

Picking the size

Serving an image larger than it is displayed is the most common waste on the web, and the fix is arithmetic rather than judgement:

• Take the widest the image is ever displayed at in CSS pixels.
• Double it, for high-density screens.
• That is your width. More is bytes nobody sees.

A photo in a 600-pixel-wide column wants to be 1200 wide. Serving the 4032 pixels straight off a phone camera means sending about eleven times the data for no visible difference at all.

Which algorithm, and does it matter?

Less than the internet suggests. Browsers use a bicubic-family filter for canvas scaling, which is the right default for photographs. The one setting worth knowing is whether smoothing is on at all: turn it off for pixel art and screenshots of text where you want hard edges, and leave it on for everything else.

For very large reductions (say 4000 pixels down to 200) doing it in two steps can look slightly cleaner than one, because a single-pass filter samples too sparsely and aliases fine detail. It is a small effect and rarely worth the trouble.

What gets stripped along the way

Resizing in a browser draws the image onto a canvas, and a canvas holds pixels and nothing else. The EXIF block does not survive: camera model, lens, timestamps, and (worth knowing) any GPS coordinates.

For a photo you are about to post somewhere, that is usually the point rather than a loss. If you need the metadata, keep the original.

One consequence to watch: rotation is often stored in the EXIF rather than in the pixels. A phone photo that looks upright in your file browser can come out rotated after processing, because the flag that was turning it went away. A tool that reads the orientation and bakes it in before resizing avoids this; if yours does not, rotating before you resize does.