Should I compress or resize first?

Resize first, compress last. Downscaling aggregates pixels and reduces noise, so the compressor then has less data to discard to reach a size target. Compressing at full resolution forces the encoder to throw away more quality, and any later resize then runs on already-degraded pixels.

Why does the browser tab freeze during a large batch?

Each image is decoded into memory at its full uncompressed size, which can be far larger than the file on disk. Browsers cap how much a single tab may use, and exceeding that usually causes a freeze or an automatic reload rather than an error message. Processing in batches of twenty to thirty, or reducing the target dimensions, avoids it.

Why did my files come out of order after renaming?

Text sorting compares character by character, so without zero-padding a sequence sorts as 1, 10, 100, 101 rather than 1, 2, 3. Pad to a fixed width, for example 001 through 200, so every name has the same number of characters.

Processing 200 photos without 200 clicks

A hundred listings, six photos each. Done one at a time that is six hundred round trips through the same dialog, and the mistakes multiply with the volume — one batch resized to the wrong dimension, one day's photos named inconsistently, one export that silently produced smaller files than the last. This page is about doing the whole batch in a way you can check afterwards.

The tools this refers to: resize, compress, white background and batch rename all accept multiple files in one drop. Processing runs on your own machine, so a large batch does not depend on an upload finishing.

What follows is the part that decides whether the batch is usable: the order to run things in, and how to catch the handful of files that quietly went wrong.

Order of operations decides the result

The same five steps applied in a different order produce visibly different quality. The rule is that every step which discards information should come as late as possible, and every step which changes geometry should come before the steps that assume a final geometry.

Order	Step	Why it sits there
1	Crop / straighten	Do this first so you are not resizing pixels you are about to throw away.
2	Background replacement	Works best at full resolution, before edges have been resampled and softened.
3	Resize to the target square	Downscaling aggregates pixels and reduces noise. Doing it before compression means the compressor has less to throw away.
4	Colour profile / format conversion	Convert to sRGB and to the delivery format at the final size, so nothing re-encodes afterwards.
5	Compress to a target file size	Last, because it is the only step that permanently discards detail. Everything after it must be lossless.

The common mistake is compressing first and resizing afterwards. That does the opposite of the table: the compressor is asked to hit a size target at full resolution, so it has to throw away far more quality than necessary, and then the downscale runs on already-damaged pixels. The visible symptom is a batch that looks noticeably softer than a single test file you ran earlier.

Second common mistake: resizing to fit a square by padding. If the source is 4:3 and the target is square, a naive resize either stretches it (products look fat) or pads it with black. Padding with the background colour you are actually using, which for a product listing usually means white, is the only version that survives review.

Why large batches stall, and what to do about it

Browser-based tools process images inside a single tab, and a tab has a memory budget enforced by the browser rather than by the page. A modern phone photo can decode to well over 40 MB in memory once uncompressed, regardless of the file being 4 MB on disk. Twenty of those at once will exceed what the tab is allowed, and the tab will typically freeze or reload rather than report an error.

That is why batch tools generally process files one at a time in a queue instead of all in parallel. It is slower in wall-clock terms and much more likely to finish. If a batch is failing partway through, the practical responses, in order of effort:

Split into batches of twenty or thirty rather than hundreds.
Close other tabs, especially anything with video or a heavy editor open.
Reduce the target dimension. An image decoded at 2000 px uses roughly a quarter of the memory of the same image at 4000 px.

Naming before processing, not after

Sort order comes from the filename in almost every tool and every upload form. Camera filenames — IMG_4821.jpg — sort in capture order, which is fine until a card fills up and the counter wraps, at which point IMG_0001 lands after IMG_9999 in a text sort.

If a listing needs the images in a specific sequence, the sequence has to be in the name before anything else runs. Zero-padding fixes the wraparound: 001 through 200 sorts correctly as text, while 1 through 200 sorts as 1, 10, 100, 101.

Two further conventions are worth adopting because they cost nothing and prevent most bulk-upload errors:

No spaces. A space in a filename becomes %20 in a URL and is handled inconsistently by upload parsers.
One separator style. Mixing _ and - across a batch makes later matching by pattern unreliable.

The batch rename tool applies a prefix, sequence and extension in one pass, with zero-padding, and the naming guide covers the marketplace-specific conventions including Amazon's identifier.variant.jpg requirement.

How to tell a batch actually succeeded

A batch that produced 200 files is not the same as a batch where all 200 files are correct. The failure modes are quiet: one file in the set was already JPEG-compressed and comes out slightly worse, one had a transparency that flattened to black, one was an odd aspect ratio that got padded on the wrong axis.

A check that takes a minute and catches nearly all of it:

Sort the output by file size. Look at both ends. The smallest file is usually the one that was over-compressed or was already low quality; the largest is usually one that failed to resize. In a uniform batch, sizes should cluster.
Open three at random — first, middle, last — at 100% zoom. Edge detail is where resampling damage shows first.
Check the dimensions of one file with a properties dialog. If the target was 2000 × 2000 and one file is 1998 × 2000, the crop snapped to a divisible size rather than stretching; that is normal behaviour, not corruption.
Count the files. If 200 went in and 197 came out, three were rejected by the browser and the tab may have reloaded without saying so.

When a desktop tool is the better answer

Being honest about the limits: browser tools are the right choice up to a few hundred files, on a machine you control, when the images are not sensitive enough to matter. They are the wrong choice when the batch is thousands of files, when it needs to run unattended on a schedule, or when the source files are too large for a tab to decode at all — a 100 megapixel scan, for example.

In those cases an image converter on the command line does the same job with better memory behaviour, at the cost of needing to write the command and check the output yourself. The trade is real in both directions, and it is worth knowing which side of it you are on before starting a batch of two thousand.

Memory limits and processing behaviour described here are properties of how browsers handle decoded image data, not of any specific platform's policy. Actual limits vary with the browser version, the machine, and how much other work the tab is doing.