Batch Processing Images Without Breaking Anything

The two habits that prevent most damage

First: process one file, open the output, and look at it. Not the thumbnail — open it at full size and check the thing you were trying to achieve. Orientation, cropping, quality, transparency, dimensions. Thirty seconds here catches the wrong output format, the crop taking the wrong region, the quality set far lower than intended, and the resize going the wrong direction.

This sounds obvious and is skipped constantly, usually under time pressure, which is exactly when the mistake is most expensive to discover afterwards.

Second: write output to a different directory from the input. Never process in place, and never let output overwrite input. If the results are wrong you delete the output directory and try again; the sources are untouched and you have lost nothing but the running time.

Processing in place is the one that turns a recoverable mistake into an unrecoverable one. A batch that overwrote four hundred originals with badly compressed versions cannot be undone, and for photographs of something that happened once, it cannot be redone either.

Sort the inputs before you start

A single set of settings is correct for a single kind of content. A folder containing photographs, screenshots, logos with transparency, and scanned documents needs four different treatments, and applying one to all of them produces three bad outcomes.

Photographs want a lossy format at a sensible quality. Screenshots and diagrams want lossless, because JPEG compression targets exactly the sharp text edges they are made of. Images with transparency must not go to a format without an alpha channel unless you have deliberately chosen the background colour. Scans may want different resolution handling entirely.

Sort into separate folders and run separate batches. This takes a few minutes and removes an entire class of error.

Watch for mixed dimensions and orientations too. A resize rule expressed as a fixed width behaves differently on portrait and landscape images, and a batch containing both frequently needs a rule based on the longest edge rather than on width.

Also check for files that are not what they appear to be — a HEIC renamed to .jpg, a file that will not decode, a zero-byte file from a failed copy. These are the ones that will fail mid-batch.

Handling failures

In any batch of real files, some will fail. Corrupt downloads, unsupported variants of a format, files that are not images at all, and files with unusual colour modes all turn up in collections that have been copied around for years.

The question is what the tool does about it, and there are three behaviors with very different consequences. Stopping at the first failure is safe but means babysitting a long run. Skipping silently is dangerous, because you end up with fewer outputs than inputs and no indication which are missing. Skipping with a report is what you want.

Whatever the tool does, count the outputs against the inputs when it finishes. A mismatch means something was skipped, and finding out now is much better than finding out when you need the missing file.

For the failures themselves, deal with them individually rather than loosening the batch settings to accommodate them. A file that fails to decode has a problem that a different quality setting will not fix.

Naming and organisation

Decide on the output naming before you run anything. Keeping the original base name with a new extension is the simplest scheme and makes it obvious which output came from which input. Adding a suffix describing the treatment — the dimensions, or the purpose — helps when several derivatives exist from the same source.

Avoid schemes that renumber sequentially unless you have a reason to. Losing the connection between input and output makes it impossible to work out which file failed, which one to re-run, and which source a given derivative came from.

Be careful with case and with characters that some systems dislike. A batch that runs on one machine and fails on another over a filename containing a colon, a question mark, or a trailing space is a tedious problem to diagnose.

Preserve the folder structure when the inputs are nested. Flattening a hierarchy into one directory usually produces name collisions, and the file that silently overwrote another is not obvious.

Consistency across the batch

Where the output is a set that will be seen together — a product catalogue, a gallery, a set of documentation screenshots — consistency matters more than optimising each file individually.

Use the same output dimensions, the same format, the same quality setting, and the same treatment for the whole set. A gallery where one image was processed differently looks like a mistake even when that image is objectively better.

This argues against per-file size targets in such sets. Compressing each image to an identical byte count means each one gets a different quality setting, so a simple image is over-compressed and a detailed one under-compressed relative to each other. A fixed quality across the set produces varying file sizes and consistent appearance, which is usually what you want.

Where a byte ceiling must be met per file, apply it as a ceiling rather than a target: use a fixed quality and only reduce further on the files that exceed the limit.

Tools for different scales

For a handful of files, a web tool or the operating system's built-in facilities are sufficient and require nothing to be installed. PixelConvert handles batches with a single set of locked settings and returns one archive, which suits the common case of preparing a set for one destination.

For recurring work on larger numbers, a command-line tool is worth the initial learning. ImageMagick is the long-standing general-purpose option and handles nearly every format and operation. The advantage over a graphical tool is not speed but repeatability: the command is a record of exactly what was done, and it can be re-run later or adapted.

For anything with conditional logic — different treatment depending on dimensions, orientation, or content — a short script is clearer than an elaborate tool configuration. Python with Pillow is a common choice and is what generates this site's own test corpus.

For work embedded in a website or application, use the framework's own image pipeline rather than pre-processing by hand. Modern frameworks generate responsive sizes and modern formats automatically, and hand-maintained derivatives go stale as the design changes.

Record what you did

Write down the settings, or better, keep the command. A batch you cannot reproduce is one you will reconstruct from memory when the same job comes round, and the reconstruction will not match.

This matters most for sets that grow over time. A product catalogue gains items; documentation gains screenshots. New files processed with slightly different settings from the originals are visibly inconsistent, and the drift is hard to spot until the set is viewed together.

A short note alongside the output directory — the date, the source, the settings, the tool and version — costs a minute and answers the question that will eventually arise. Where the work is scripted, the script is the note.

And verify the batch before deleting anything. Count the files, spot-check several from different parts of the set rather than only the first, and confirm the outputs open correctly. Only then consider the sources safe to archive — and archive rather than delete, if they are originals.