Set the size the picture needs

What changes a picture’s dimensions

Every picture this tool reads is decoded to plain pixels before anything is written, so changing its size means choosing how many of those pixels the output keeps. Two controls do that, and both are off until you turn them on, which is why an unconfigured run gives you a file the same size as the one you chose.

The output row tells you the pixel dimensions of the finished file, so you can check the number you wanted rather than assume it. It also shows the size before and after and both pictures side by side, so a resize that turned out to have changed more than the size is visible before you download. Nothing is uploaded: the resize happens in your browser.

Setting a width in pixels

Choose by width and the output is exactly that many pixels wide. The height is not typed: the tool works it out from the picture’s own proportions and rounds it to the nearest pixel, never below one. A 3:2 photograph at 1280 comes out 1280 by 853, and a 16:9 one at 1280 comes out 1280 by 720.

This is the mode to use when something downstream states a number: a theme’s image width, a newsletter’s attachment limit expressed as pixels, or a print service that wants a specific long edge. Because only the width is set, a very tall picture at a generous width can still come out with more pixels than you expected. The number in the row is the check.

Setting a percentage

Choose by percent and both sides become that share of the original, each rounded to the nearest pixel. Half is half on each side, so a quarter of the pixels, and it is the mode that keeps a picture’s shape obviously the same. Because both dimensions scale together, the proportions are preserved by construction.

The percent field stops at 100. That is a boundary worth stating plainly: this mode shrinks a picture and cannot enlarge one. A width, by contrast, is only a target width, and setting it above the picture’s own width does enlarge the output. Enlarging does not recover detail the encoder threw away, and it usually makes the file bigger rather than smaller, so if your goal is a smaller file stay below the original in either mode.

Rounding, and why the height is not always what you predicted

The height is a whole number of pixels, and the tool rounds rather than truncates, so a height that would land on a half pixel goes to the nearer whole one. On most pictures the difference is invisible. On an extreme shape it can be a pixel, which is the smallest unit there is.

Rounding is applied after the orientation, and it is applied to the picture as it will be stored. That matters for one common surprise: if your camera stored a rotation in the file, the tool applies it to the pixels first, and a width you type is then the width of the picture as you see it, not the width in the file’s stored numbers.

The orientation case in detail

EXIF orientation is a number from 1 to 8 that tells a viewer how to turn a stored picture upright. The tool applies it to the pixels, so the output is right way up and carries no orientation to interpret.

The four values that include a quarter turn, 5 to 8, swap the width and the height: a file whose stored numbers read 600 by 400 and whose orientation says 6 comes out 400 by 600. Files tagged 5, 7 and 8 swap the two numbers in the same way. The other four values leave both numbers alone, so a 180 degree turn (3) or a mirror (2, 4) comes out the same size as it went in, just reoriented.

One input format does not carry its orientation into the tool at all. An AVIF file’s EXIF block is not read, so an AVIF is used exactly as it is stored. If you are resizing AVIF files and the dimensions do not match what the picture looks like, that is the reason, and rotating it first is the workaround.

What a resize does to the rest of the file

Resizing removes pixels and encodes what is left, so a lossy output format still applies its own quality setting: the quality control runs on the resized picture, not on the original. PNG is the exception, since it is lossless and ignores quality entirely, though a PNG output still gets a second pass through oxipng that can return fewer bytes than the first encode.

Resizing is not a metadata operation. Outputs carry no EXIF unless you ask to keep it, and the keep control writes the block back into a JPEG, PNG or WebP output only.

Limits worth knowing before you resize

An input larger than 32 MiB, or one with more than 40,000,000 pixels, is refused before it is decoded. The pixel limit is a property of the file you chose, so it applies to the input and not to the output: a 45,000,000 pixel photograph is refused however small you asked to make it, because the tool has to decode it to resize it at all. Both numbers are fixed rather than a reading of your machine. A refused file names the limit that refused it, and the other files in the batch still finish.

You can resize several files in one run: the run starts one worker for every core your browser reports, never more workers than files, and each worker takes the files one after another. For AVIF output the encoder has threads of its own, so those cores are shared between the encoder’s threads and the files. A device with little memory starts fewer workers, because each one needs room for a decoded picture and a codec. Changing a control does not disturb the results already on screen. Pressing start again runs the files you chose once more with the settings as they are now, and rebuilds the rows from that run.

What to do next

Set the width if something downstream states a number, or the percentage if you want the picture smaller in proportion. Check the dimensions in the row before you download. If the file still has to be under a size in kilobytes rather than merely smaller, the target size page covers that, and if the format itself is the problem the WebP page covers converting it.