The job that broke me was 200 product images, all needing the same crop-and-resize sequence for a client’s e-commerce catalog. I sat there for six hours clicking the same four menu items in the same order, watching my afternoon dissolve into a kind of professional purgatory. By image 140, I made myself a deal: I would spend whatever time it took that weekend to make sure this never happened again.

That was fifteen years ago. I have not manually repeated a task like that since.

What Actions Can Do and Where They Hit a Wall

Most photographers who use Photoshop actions treat them like a macro recorder, which is exactly what they are. You hit record, do your thing, hit stop. Photoshop writes down every step. Play it back on another file and it replays those steps in sequence. For consistent, linear workflows, actions are genuinely excellent. A sharpening sequence, a skin tone curve adjustment, a watermark stamp - anything where the steps never need to think, actions handle cleanly.

The limitation is that actions have no decision-making capacity. They cannot look at an image and respond to what they see. If you record an action that moves a layer to coordinates 450px by 200px, it will do exactly that on a 800x600 file and on a 4500x3000 file, without caring that those coordinates mean something completely different at each resolution. Actions follow instructions. They do not read context.

Where JavaScript Enters the Conversation

Photoshop’s scripting engine accepts JavaScript, AppleScript, and VBScript. JavaScript is the one worth learning, partly because it is the most documented, and partly because the Photoshop DOM (Document Object Model) is reasonably well-structured once you get your bearings.

A script can do things an action cannot. It can check the width and height of a document before deciding where to place an element. It can loop through every layer in a file and rename them based on a naming convention you define. It can read from an external text file or spreadsheet and use that data to populate text layers, which is exactly how I build product shot variants for ad agencies without touching each file individually. The script is not replaying a recording. It is executing logic.

A basic JavaScript file for Photoshop starts with app.activeDocument to reference your open file, and from there you can access layers, artLayers, layerSets, and properties like bounds to get pixel dimensions. Adobe’s scripting reference guide is free and downloadable as a PDF. It is dry reading, but it is accurate.

Building a Batch System That Actually Scales

Here is the structure I use for any batch job involving more than 50 files. First, I separate the logic from the interface. The script itself lives in a .jsx file that does one job well, like resizing every image in a folder to 2000px on the long edge while preserving aspect ratio, sharpening with Unsharp Mask at 85%, 1.2 radius, 4 threshold, and exporting as a JPEG at quality 9. That is the worker.

The trigger is Photoshop’s built-in File > Automate > Batch command, which can run any action, but can also be paired with a droplet - a standalone application built from your action pipeline that accepts dragged folders. I combine the two by wrapping the script inside an action using the Insert Script Item function, which many people do not know exists. This lets me keep the benefits of both systems: the action handles static steps, the script handles anything requiring conditional logic.

For a recent e-commerce client running roughly 300 SKUs per week, this pipeline processes a full batch in under 40 minutes. That same job done manually, even by a fast retoucher, runs 6 to 8 hours.

The Anecdote I Tell Every New Client

A few years ago, I took on a weekend project for a regional ad agency that needed 500 product images processed before a Monday morning presentation. New backgrounds, consistent shadow drops, resized for three different output specs. I had built a batch system the previous month for a similar job, so I spent Saturday afternoon adapting it for their file naming convention and output folders, testing it on 20 images, adjusting the shadow opacity from 35% to 28% because their preferred style ran lighter, and then I let it run.

Sunday morning, every file was done. I spent that afternoon reviewing for exceptions, found 11 images that needed manual fixes due to transparent packaging that confused the background replacement logic, fixed those by hand, and delivered the full set Sunday evening.

The agency assumed I had a team working through the weekend. I did not. I had a .jsx file that was about 180 lines long and a folder of presets I had refined over two years of similar jobs. The leverage in that situation was not talent or speed. It was the system.

The One Habit That Protects Everything

I keep every script version-controlled in a folder structure organized by client and job type, with a plain text changelog inside each folder noting what was adjusted and why. When a client’s spec changes - and it always changes - I am not rebuilding from scratch. I am editing line 47 of a file that already knows what it is doing.

The script is only as reliable as the discipline around it. If you treat automation as a one-time shortcut, you will keep rebuilding the same shortcuts. If you treat it as infrastructure, you build something that compounds.