The day I truly understood the difference between a Photoshop action and an automation script, I was sitting in front of 200 product images that all needed the same crop, the same resize, and the same file naming convention. I did the first one manually. Then the second. By the fourth I was already building the action. By the tenth I realized the action wasn’t going to be enough, because every image had a slightly different canvas size coming out of the camera tether, and the action kept choking on the math.

That was the afternoon I opened ExtendScript Toolkit for the first time. It changed how I work in a way that nothing has since.

What Actions Can Do and Where They Hit a Wall

Photoshop actions are recorded sequences. You hit record, do the thing, hit stop, and Photoshop writes down every step in order. For a fixed, repeatable process on uniform files, they are genuinely excellent. I have an action set I built for e-commerce white-background cleanup that runs in about four seconds per image and handles 90% of what a junior retoucher would spend eight minutes doing by hand.

But actions are brittle. They don’t make decisions. If your action says “resize canvas to 2000x2000 pixels” and the incoming file is already 2200 pixels wide, the action either fails or produces something wrong, depending on how you built it. Actions also can’t read filenames, can’t talk to spreadsheets, can’t skip files that already exist in the output folder, and can’t log errors. They’re a recording, not a program.

What JavaScript Actually Does Inside Photoshop

Photoshop’s scripting engine runs JavaScript through an interface called the DOM, the Document Object Model. Every layer, every document, every pixel selection is an object your script can query and manipulate. When you write app.activeDocument.width, you’re asking Photoshop to return the actual pixel width of whatever file is currently open. You can feed that number into a calculation, make a decision based on it, and then act accordingly.

This is the gap that matters. A script can open a file, check its dimensions, calculate the correct crop ratio to reach a 1:1 output without upscaling, apply that specific crop, rename the file based on metadata pulled from a CSV, save it as a JPEG at quality 10 (roughly 60-70% quality in Photoshop’s internal scale, not the misleading percentage shown in the dialog), and log the result to a text file. Then it moves to the next file and does it again, 500 times if you need it to.

That’s not an action. That’s a small piece of software.

The Three-File System I Use for Every Batch Job

When I set up a scripted batch workflow for a client, I work with three files: the script itself (.jsx), a CSV that serves as the job manifest, and a log file the script writes to as it runs.

The CSV contains one row per image: source filename, output filename, target dimensions, and any job-specific metadata like SKU numbers or color space requirements (sRGB for web delivery, ProPhoto RGB for print handoffs). The script reads each row, finds the source file, processes it, saves it to the output folder, and writes “SUCCESS” or an error message to the log.

The log file is what saves me in client situations. When someone from an ad agency emails asking why image SKU-4471 looks different from the rest, I open the log and find out that file was 72 DPI instead of 300 and the script flagged it, skipped the resize step, and noted the exception. I have an answer in 30 seconds instead of opening the file and reverse-engineering what happened.

The Weekend I Built a 500-Image Pipeline and What I’d Do Differently

A few years ago I took on a product shoot for an e-commerce brand, 500 SKUs, two angles each, all needing white background cleanup, shadow compositing, and three output sizes (2000x2000 for the main listing, 800x800 for thumbnails, 1200x628 for social). That’s 3,000 output files from 1,000 source images.

I spent a Saturday building the script and testing it on a sample set of 20 images. Sunday morning I ran the full batch while I had coffee. It finished in about four hours of unattended processing. The whole weekend including testing cost me maybe six hours of actual work.

What I’d do differently: I’d build the error threshold in from the start rather than adding it after the first test run crashed on a corrupt file. The script now stops and logs a warning if more than 5% of files in a job throw exceptions, rather than silently continuing and handing back 50 broken outputs at the end of a run. That five-percent rule has saved me from delivering bad work twice.

Learning the Syntax Without Learning to Be a Developer

You don’t need a programming background to write useful Photoshop scripts. The Photoshop Scripting Guide, available as a free PDF from Adobe, documents every object and method in the DOM. The community at the Adobe Photoshop Scripting forum is active and genuinely helpful. And because Photoshop’s JavaScript implementation is fairly self-contained, you’re not trying to learn web development or Node.js at the same time.

Start with a script that does one thing: open a file, resize it to a fixed dimension, save it as a JPEG, close it. That’s about fifteen lines of code. Once that works, add the loop that processes a folder instead of a single file. Once that works, add the CSV reader. Build in layers, test at every stage, and keep old working versions before you change anything significant.

The gap between someone who uses Photoshop and someone who runs Photoshop is a few weekends and a willingness to read documentation. The return on that investment, measured in hours rather than enthusiasm, is the most reliable one I’ve found in fifteen years of working in studios.