Resizing two hundred product photographs one at a time is not a task anybody finishes. The interesting question is not whether to do it in a batch, but where the batch runs — and the answer changes the job from a twenty-minute wait into three seconds, or the other way around, depending on one number you can work out in advance.
That number is the total size of the files.
Why batch resizing feels slow
Resizing an image is cheap. A modern browser can scale a twelve-megapixel photograph to a thousand pixels wide in well under a second, because it is arithmetic on a grid of numbers and the hardware is built for exactly that.
What takes time in a cloud-based workflow is not the resizing. It is moving the files to the machine that does the resizing and moving the results back. The computation is a rounding error next to the transfer.
The bandwidth arithmetic
This is worth working out before choosing an approach, because the result is usually decisive.
- Two hundred photographs at 3 MB each is 600 MB to upload. On a typical home connection with 20 Mbps of upstream capacity, that is roughly four minutes of sustained transfer, assuming nothing else is using the line and nothing fails.
- The resized results come back down at perhaps 200 KB each, so 40 MB — trivial, and irrelevant, because the upload is what dominates.
- The same job locally reads 600 MB from disk and writes 40 MB back. No network involved, and disk access is an order of magnitude faster than a consumer upstream link.
So the cloud route costs four minutes of waiting plus a failure mode — a dropped connection at photograph 180 means starting again, or at least repairing. The local route costs a few seconds and cannot fail that way.
The arithmetic flips on a fast connection with a small batch. Ten images totalling 30 MB will upload in seconds, and the convenience of a server-side pipeline may well be worth it. The mistake is applying that reasoning to two hundred files without checking.
What a browser does with two hundred files
Handling a batch locally is more achievable than most people assume, but it has a shape worth understanding.
- Multi-select is native. A file input accepts an entire folder or a hundred selections, and the File API gives you each one as an object you can read without transmitting it.
- Web Workers keep the interface alive. Processing runs off the main thread, so the page does not freeze while the batch works through.
- Memory is the real constraint. A browser tab has a memory ceiling, and a hundred twelve-megapixel images decoded simultaneously will reach it. Well-built tools process in sequence or in small parallel groups and release each image as it finishes.
- Results are downloaded, not stored. The output arrives as files. Some tools produce a ZIP, which is convenient for a large batch but means one enormous download at the end.
When the cloud is the better answer
Local is not automatically right, and there are situations where a server is genuinely the correct architecture.
- The files are enormous. Multi-hundred-megabyte assets belong on a machine with more memory than a tab is allowed.
- The job has to run on a schedule. A nightly pipeline that picks up new uploads cannot depend on someone having a browser open.
- It is part of a larger build. If images are resized on the way into a content management system, a server-side step is the natural place for it.
- You need a shared, auditable result. A team workflow where everyone works from one canonical set of derivatives needs a central place for them.
When local is the better answer
Four situations where the local approach is not just faster but materially better.
- The images are confidential. Unreleased product photography, client material under NDA, or anything showing identifiable people or premises. Not sending the files is the only version of this that cannot go wrong.
- It is a one-off job. Creating an account, verifying an email and reading a pricing page to resize a folder once is a poor trade.
- The connection is unreliable or metered. On a train, on hotel Wi-Fi, or on a mobile hotspot, uploading 600 MB may be impossible rather than merely slow.
- You are iterating on settings. Trying four quality levels across the same set means four round trips to a server. Locally it means four passes over files already in memory.
The mistakes people make when batching
Batching introduces failure modes that single-file work does not have.
- Using one setting for a mixed set. A flat product shot and a photograph of foliage need different quality levels. If the set is mixed, split it rather than picking a compromise that is wrong for both halves.
- Renaming destructively. Sequential filenames from a camera are the only reliable ordering. A tool that renames everything to image-001 destroys it. Check what happens to names before committing to a batch.
- Resizing the results again. Re-encoding an already-resized file adds a generation of loss for nothing. Always work from the originals, and keep them.
- Enlarging to reach a minimum. If a requirement says 1600 pixels, a 900-pixel source cannot be made into one. Upscaling invents pixels and the result will be rejected or will look wrong.
- Rotating twice. Some formats and pipelines apply an orientation tag rather than rotating pixels, and applying it twice cancels it out. This is why a batch sometimes comes out sideways after a resize that seemed innocuous.
A workflow that holds up
Copy the originals to a working folder, keep them untouched, and treat the output as disposable. Decide the target dimensions and quality from one representative image before running the batch, not while looking at two hundred results. Check the names survived. Then spot-check three files — the smallest, the largest, and the busiest — at 100 percent zoom.
The image toolkit does rotate, flip and resize in the browser, so a batch of two hundred photographs is processed on your machine with no upload at all — which is the point of the arithmetic above. If the real goal is file size rather than dimensions, compressing the set is the correct operation, and doing both in the right order — resize first, then compress — is worth about a factor of three in the final result.