There’s a specific kind of misery that comes from doing the same Photoshop operation 200 times in a row. I know it intimately. Early in my career, before I understood what scripting could do, I spent an entire day manually cropping and resizing product images for a catalog client. Same crop. Same resize. Same save. Over and over, for eight hours. By the end of it I was making errors I wouldn’t normally make on my worst day, because repetitive manual work degrades your attention whether you like it or not. That afternoon is what pushed me to actually learn JavaScript inside Photoshop, and it’s the reason I haven’t manually repeated a task since.

If you’re using Photoshop actions and stopping there, you’re leaving the most powerful part of this toolset completely untouched.

What Actions Can’t Do Alone

Photoshop actions are excellent at recording a fixed sequence of steps and replaying them. But they have hard limits. They can’t make decisions. They can’t read file metadata. They can’t loop through a folder, evaluate each image individually, and apply different adjustments based on what they find. They also fail silently in ways that are genuinely dangerous when you’re processing hundreds of files, since you won’t know something went wrong until a client calls.

What actions do well is define the operations. What scripting does is control when, where, how many times, and under what conditions those operations run. The two tools are not in competition. A well-built production system uses both: actions handle the pixel-level work, scripts handle the logic layer wrapped around them.

Photoshop’s scripting engine runs JavaScript (ExtendScript, technically, though Photoshop 2022 and later also supports UXP). The API gives you access to nearly everything in the application, including the ability to call existing actions by name using app.doAction("Action Name", "Action Set Name"). That single function is the bridge between your recorded actions and a fully automated pipeline.

Building the Logic Layer

Here’s the actual structure I use for e-commerce batch jobs. The script opens a source folder dialog, reads every JPEG and TIFF inside it, opens each file, runs a predefined action set, exports to a destination folder with a naming convention tied to the original filename, then closes the document without saving. The whole thing is maybe 60 lines of JavaScript.

The key variables I always define at the top of any batch script:

  • Source folder path
  • Destination folder path
  • Target file format and quality setting (for JPEG, I use a quality value of 10 out of 12 for most e-commerce work)
  • Output resolution (typically 72 PPI for web, 300 PPI for print-ready files)
  • File naming prefix or suffix

That last one matters more than people think. If your output files overwrite your source files because you forgot to set a destination path, you’ve just destroyed your originals. I have three external drives for a reason.

The loop itself uses Photoshop’s Folder and File objects to iterate through the source directory, filter by file extension using a simple match() check, and process only the files you want. Add a try/catch block around the core processing call, and any file that throws an error gets logged to a text file instead of silently failing. You end up with a clean error report after every batch run.

The Action Set That Does the Heavy Lifting

The script is only as good as the action it calls. For product photography, my standard action set for e-commerce clients includes five steps in this order: auto-straighten via Content-Aware, background neutralization using a Curves adjustment targeted to the highlights, a smart sharpen pass at 85% strength with a 0.6-pixel radius, conversion to sRGB color space, and a canvas resize to 2000x2000 pixels with the image centered. That sequence took me about two hours to dial in correctly, but it now runs on thousands of files a year without me touching it.

The important technical note: when your script calls an action, it runs in the context of the currently active document. That means your action cannot contain any step that opens a new file or changes the active document, or the script’s document reference will break and subsequent operations will apply to the wrong file. Keep actions self-contained. Everything that touches the file system should live in the script, not the action.

The Day the System Actually Paid for Itself

A few years into running my consultancy, an ad agency client came to me with 500 product shots from an overseas studio, all needing the same corrections and formatting before going to their e-commerce platform. The deadline was two business days. Under the old manual approach, that job would have taken most of a week.

I spent a weekend building and testing a batch script specifically for their deliverable specs: 1500x1500 pixels, sRGB, JPEG at quality 10, with a naming convention tied to their SKU numbers pulled from a CSV using a small Node.js helper script I wrote to pre-rename the files. Monday afternoon, I ran the batch. The whole 500-image set processed in about three hours while I worked on something else. I invoiced for the full estimated time, delivered ahead of schedule, and that client has been with me for four years.

I track these things obsessively. The spreadsheet I keep on saved hours from automation is currently sitting at over 2,400 hours since I started logging it. That’s not a brag, it’s a measurement, and measurement is how you know whether a system is actually working.

When Scripts Break (and How to Catch It)

No automation is bulletproof. The most common failure points I’ve seen are mismatched color profiles triggering dialog boxes that pause execution, corrupt source files that cause uncaught errors, and actions that include a “Save As” step that overrides the script’s export path. All three are solvable. Set displayDialogs to DialogModes.NO at the start of your script to suppress profile warnings. Wrap file opens in a try/catch. And audit every action you plan to call from a script before you deploy it at scale, since steps that work fine interactively can behave differently in a scripted context.

The real value of learning to script is not the time it saves on any single job. It’s that you stop thinking about production as a series of tasks and start thinking about it as a system you design once and run indefinitely. That shift changes how you price work, how you take on volume, and honestly how much you enjoy the job.