The task was 200 product images. All of them needed the same crop, the same resize, the same output path. I sat down at 9am and started working through them manually because I hadn’t yet learned to build the solution I needed. By 2pm I had finished maybe 60, my wrist hurt, and I had made three cropping errors I’d have to go back and fix. That afternoon, I opened Google and searched “Photoshop batch processing.” What I found changed how I work permanently.

That was fifteen years ago. I still track the hours saved in a spreadsheet. The number is over 2,400 now.

Why Actions Alone Aren’t Enough

Most photographers discover Photoshop Actions first. You record a sequence, hit play, done. For single images or small sets, that’s fine. But Actions have real limitations that become obvious the moment you try to scale them.

Actions are sequential and rigid. They don’t make decisions. If you record an action that sharpens a layer called “Retouch,” it will fail or produce garbage on any file where that layer doesn’t exist or has a different name. Actions also can’t read file metadata, can’t rename outputs dynamically, and can’t branch based on image dimensions. They’re a tape recorder, not a brain.

Photoshop Scripts, written in JavaScript (or ExtendScript, Adobe’s older dialect), are what actually gives you control. A script can check whether a layer exists before touching it. It can read the filename, parse a SKU number out of it, and name the export accordingly. It can loop through an entire folder, apply different settings based on image orientation, and log any errors to a text file you review afterward. That’s the difference between a one-trick macro and a real automation system.

The File-Naming Problem Nobody Talks About

Here’s something that bites e-commerce operations constantly: inconsistent output naming. An ad agency sends 300 images with filenames like “PROD_4421_hero_v2_FINAL_USE THIS ONE.jpg.” Your client’s CMS needs files named “4421-hero.jpg.” Doing that rename manually, per file, is the kind of work that makes people leave the industry.

A simple ExtendScript loop handles this in under a minute of processing time. You open the script, define your input folder, write a regular expression that pulls the SKU number from the original filename, and tell Photoshop to save each processed file with the cleaned name. For a batch of 300 images, you’re looking at setup time of maybe 20 minutes the first time you write it. Every subsequent run takes less time than it takes to pour a coffee.

The script I use for e-commerce clients runs a sequence: it opens the file, checks the canvas dimensions, resizes to 2000x2000 pixels at 72dpi if it’s square or flags the file in a rejection log if it isn’t, runs a sharpening action I’ve built separately, flattens, exports as JPEG at quality level 10 (roughly 85% in standard terms), and saves to a client-specific output folder. That output folder path is the only variable I change between clients. Everything else is locked.

Building the Bridge Between Scripts and Actions

The most efficient system I’ve landed on is a hybrid: Actions handle the visual processing work (color grading, retouching, sharpening), and Scripts handle the logistics (file management, naming, folder routing, error handling). They talk to each other using Photoshop’s built-in app.doAction() method.

So a script opens image file number one, calls a named Action set, waits for it to complete, then takes over again for the export and save sequence. This way I can update the visual processing piece inside the Actions panel, without rewriting any code. Designers on my team who don’t write scripts can still modify the look-and-feel of the output. The script doesn’t care what the Action does internally, only that it exists and completes without error.

One practical note: always wrap your doAction() calls in a try-catch block. If an Action fails mid-batch, a script without error handling will just stop, and you’ll have no idea how far it got. A try-catch lets the script log the problem file, skip it, and keep processing the rest of the folder.

The Weekend That Paid for Itself a Hundred Times Over

A few years into running my own consultancy, I landed a contract with an e-commerce brand that had 500 product shots coming in from three different photographers, shot on two different background setups, with inconsistent white balance across the lot. The deadline was tight. I spent a Saturday building a batch system: one script to route files by background type into two folders, one Action set per background with the appropriate color correction baked in, and one final script to process both folders sequentially and dump everything into a single client-ready export folder.

Sunday, I ran it. The whole batch processed in about 40 minutes. I spent another hour spot-checking and fixing maybe 8 files that had unusual exposure problems the automation couldn’t handle cleanly. That’s it. A job that would have taken two full days of manual work took roughly a half-day of build time and less than two hours of total execution and review. The client got their files early. I billed for the full estimated time because the result was identical.

That system still runs. I’ve adapted it for at least a dozen clients since. The original weekend of work has probably compressed 60 or 70 hours of labor by now.

One Place Where Automation Fails You

Knowing when not to automate matters as much as knowing how. Retouching decisions that require human judgment, composites where the client’s brief changes mid-project, color work on hero images that will appear in print, these don’t belong in a batch script. Automation is for consistency and volume. The moment a task requires aesthetic judgment call by call, you want a human eye on every frame.

The practical test I apply: if I could hand this task to a careful intern with a clear checklist, I can probably automate it. If I’d have to sit next to that intern and make decisions with them the whole time, automation won’t help me.

The real power of scripted automation isn’t speed for its own sake. It’s freeing up the hours you’d spend on repetitive execution so you can spend them on the work that actually requires you.