The job came in on a Thursday. Five hundred product images, all needing the same treatment: background removal, shadow drop, color correction to a specific brand profile, resize to 2000x2000 at 72dpi, and export as sRGB JPEGs under 500KB each. The client needed them by Monday morning.

A few years ago, that would have meant a miserable weekend. Instead, I had them done by 4pm Friday and spent the rest of the afternoon with my kids. That’s not luck. That’s a batch system I built over one weekend that I’ve used hundreds of times since.

What Photoshop’s Batch Command Is Actually Doing

Most people treat the Batch command (File > Automate > Batch) like a glorified macro player. It’s more than that. When you run a batch operation, Photoshop is executing your recorded action against every file in a source folder, with full control over how errors are handled, where files are saved, and whether the action’s own Save step is overridden by the batch dialog.

That last part matters more than people realize. If your action includes a “Save As” step, Photoshop will honor it during batch, which means you can accidentally overwrite your originals if your folder structure isn’t set up correctly. The override checkbox in the batch dialog, “Override Action ‘Save As’ Commands,” tells Photoshop to ignore whatever save destination is baked into the action and use the batch destination instead. This is the single most important setting in that dialog. Check it every time.

The other setting most people miss is the error handling dropdown. Set it to “Log Errors to File” rather than stopping on the first problem. With 500 files, you will hit at least a few that have unexpected color profiles or layer structures. You want the job to finish and a report waiting for you, not a stalled process you’ll find an hour later.

Building the Action the Right Way Before You Batch Anything

A bad action run once is a minor annoyance. A bad action run 500 times is a disaster. Before I batch anything, I test the action against at least 10 files that represent the range of edge cases in the job: the smallest file, the largest file, one with an embedded ICC profile, one without, one that’s already sRGB, one that’s Adobe RGB.

For product work specifically, I record my actions with the color profile conversion as the first step, not the last. Everything in my action chain runs in sRGB from the first operation. If you apply sharpening or shadow effects before converting color space, you’ll get slightly different results depending on the source file’s profile, and at 500 images you won’t catch the drift until a client does.

For the job I mentioned above, the action ran in this order: Convert to sRGB (Edit > Convert to Profile), apply the brand’s saved color lookup table, run a Curves adjustment recorded at specific input/output values the client had provided, apply a 1px Gaussian Blur followed by Unsharp Mask at 85/0.8/3, flatten, resize via Image Size to 2000x2000 bicubic automatic, then Save As JPEG at quality 9 to a subfolder called “export_ready.”

That action took about 40 minutes to build and test. It saved approximately 22 hours of manual work.

Folder Structure Is Half the System

I am particular about folder organization, which my colleagues find either reassuring or exhausting depending on the day. For any batch job, I use a three-folder structure inside the main job folder: “originals,” “working,” and “export_ready.” The batch source is always “working,” never “originals.” Originals are read-only, full stop. I have an external drive for backups and a second external drive as a backup to that.

Before the batch runs, I flatten copies of the PSDs into TIFFs and drop them into “working.” This decouples the batch process from my layered source files and gives me a clean re-run path if something goes wrong. With a 500-file job, something will always go wrong.

The naming convention matters too. I use a Droplet, which is an action saved as a standalone application (File > Automate > Create Droplet), rather than the Batch command when I need to preserve the client’s original filename structure. You drag a folder onto the Droplet’s icon, it processes every file, and you can set it to append a suffix like “_web” or “_final” to each output filename without touching the originals. That naming trail is how I reconstruct what happened when a client comes back three weeks later saying one file looks different from the others.

The One Thing Droplets Can’t Do That Scripts Can

Droplets handle linear action sequences beautifully. Where they fall short is conditional logic. If you need Photoshop to make a decision, such as “if this file is wider than 3000px, do this; if it’s smaller, do that,” you need a script.

I came to scripting the hard way. I once spent an entire day doing the same crop-and-resize manually across 200 images because I couldn’t figure out how to get my action to handle both landscape and portrait orientations without distorting either. The fix, once I actually learned it, was about 15 lines of JavaScript using Photoshop’s ExtendScript toolkit. The script checked the document width against height, applied the appropriate crop ratio, then handed off to my existing action for the rest of the processing chain. The whole thing ran in under 8 minutes.

You don’t need to become a developer to use scripting. You need to know enough to write one conditional statement and call an existing action by name. There are solid references in Photoshop’s built-in scripting guide under Help > Scripting, and a few dozen existing scripts in the community that cover the most common conditional cases for photo work.

The honest truth about batch automation is this: the system pays for itself the first time you use it correctly, but the setup has to be rigorous before a single file runs. Build the action carefully, test it against your edge cases, lock your originals, and trust the log file to tell you what went wrong.