How to resize hundreds of photos at once, without uploading them
Updated 7 min read
Resizing one photo is trivial. Resizing four hundred is a different problem, and the thing that makes it different is not volume — it is that you have to make one decision that has to be correct for every file, including the ones you have not looked at.
Pick a mode that survives a mixed batch
Most batches contain both portrait and landscape images. That single fact rules out most of the ways people size things.
Fixed pixel dimensions — “make everything 1200 x 800” — only works if every file already has that aspect ratio. Otherwise something is stretched or cropped, and you will not notice which until later.
Percentage keeps every file’s proportions, but scales relative to each original. A batch containing a 6000 px photo and a 1200 px screenshot, run at 50%, produces a 3000 px file and a 600 px file. If they are going to the same place, that is not what you wanted.
Longest edge is the one that generalises. “No side longer than 2000 px” caps a landscape photo at 2000 wide and a portrait photo at 2000 tall, preserves every aspect ratio, and leaves anything already smaller alone. For a mixed folder heading to a single destination, it is almost always the right choice.
Use fixed pixels only when the batch is genuinely uniform — product shots from a fixed rig, exports from one template, frames from one video.
Decide the number once
Work backwards from where the files are going:
- Web page content images: 1600 px longest edge covers ordinary screens and most high-density displays at typical display widths.
- Full-width hero images: 2400 px.
- Email attachments: 1200 px. The point is the total size of the message, not the fidelity of any one image.
- Upload forms with a size limit: work down from the limit rather than up from a guess — see the file size guide.
- Archive or print: do not resize. Keep the originals and resize copies.
That last one is worth saying plainly: resizing is not a storage strategy. Once the pixels are gone they are gone, and a smaller copy is worth less than the original for anything you have not thought of yet. Batch-resize into a new folder, never over the top of your only copy.
The order that costs you the least
When a batch needs more than one operation:
- Rotate anything that came in sideways, so you are judging the rest on the picture as it will be seen.
- Crop — including a centre crop to a common ratio, if the batch needs one shape.
- Resize, so the target dimension is calculated on the area you are actually keeping.
- Convert last, so a lossy format is written exactly once.
Reversing steps 3 and 4 is the common mistake. Converting to JPEG and then resizing means the image is compressed, decompressed and compressed again, and the second pass has the first pass’s artefacts baked into it as if they were detail.
Working through the queue
The practical shape of the job is: add everything, tick the files you want, adjust once with apply to all selected files on, then export.
A few things that save time:
- Add a whole folder by dragging the folder itself, rather than opening it and selecting the contents.
- Deselect rather than delete. Unticking a file leaves it in the queue in case you change your mind; removing it means adding it again.
- Check one representative file before running the batch. Export a single image, open it, and confirm it is what you expected. Two minutes here beats re-running four hundred files.
- Pick the resampling mode to match the content. Smooth blending for photographs; sharp sampling for screenshots of low-resolution interfaces, pixel art and QR codes, where blending turns crisp edges into grey mush.
Where large batches actually fail
Doing this in the browser means there is no server-side limit, and also no server to absorb the work. The constraints are your own machine’s.
Memory, not file count. Each image is decoded to raw pixels while it is being processed — roughly width x height x 4 bytes, so a 50 MP photo occupies about 200 MB decoded regardless of how small the JPEG on disk was. Files are processed one at a time and released, so a hundred large photos is fine on a laptop; the same batch on a phone with other apps open may not be.
Phones are the real limit. If a batch fails partway on a mobile browser, split it into groups of twenty or thirty. It is not a fault in the files.
The ZIP is assembled in memory too. A very large batch of very large outputs can run out of room at the packaging stage rather than the processing stage. Splitting the batch fixes it.
Do not navigate away. Everything lives in the page. Closing the tab mid-run loses the work, because there is nothing on a server to come back to.
Naming the output
A folder of IMG_4821.jpg renamed to IMG_4821.jpg at a different size is a filing problem waiting to happen. Use the filename pattern to mark what these files are — a -1600 suffix, or a prefix naming the destination — so that six months from now you can tell the resized copies from the originals without opening them.
A note on what does not change
Resizing changes the pixel count and nothing else about how the image is understood. It does not change the DPI in any meaningful sense — DPI is a metadata number that tells a printer how large to render the file, and it has no effect on screens. It does not fix colour, exposure or orientation metadata. And it cannot recover detail, which is why enlarging is off by default: spreading the pixels you have over a larger area produces softness, not resolution.