The job that broke me was a Tuesday in February, maybe eight years into my career. I had 200 product images that all needed the same crop, the same canvas resize, and a filename with a specific SKU prefix. Eight hours later, I had finished them. Eight hours of clicking the same five buttons, in the same order, 200 times. I went home, opened my laptop, and spent the next four hours learning JavaScript for Photoshop. I have not manually repeated a task like that since.

That afternoon is what I think about every time someone tells me they’re “already using Photoshop actions” and doesn’t understand why they still feel stuck in repetitive work. Actions are the starting point. Scripts are where actual automation lives.

Why Actions Alone Hit a Ceiling Fast

A Photoshop action is a recorded macro. It plays back a fixed sequence of steps in the exact order you captured them. For simple, consistent work, they’re genuinely powerful. I still use them daily. But actions can’t make decisions. They can’t read a filename, check an image’s pixel dimensions, or behave differently based on what layer is currently selected. They’re a tape recording, not a program.

What breaks people is trying to use actions for work that requires conditional logic. If you’re processing a product catalog where some images are already sRGB and others are Adobe RGB, an action that converts color profiles will destroy the ones that are already correct. It doesn’t know the difference. It just runs.

This is where ExtendScript (the older Photoshop scripting language, based on JavaScript) and the newer UXP scripting environment come in. Scripts can read file metadata, branch based on conditions, loop through folders, rename output files dynamically, and communicate with the operating system. An action records what you did. A script tells Photoshop what to do and why.

The Anatomy of a Useful Automation Script

Here’s a concrete example from my current e-commerce workflow. I have a script that processes raw retouched files for a client who sells furniture. The specs are rigid: 2000x2000px sRGB JPEG at 72dpi, max file size 500KB, filename formatted as [SKU]-HERO-01.jpg.

The script does the following in sequence: opens each layered PSD from a source folder, checks if the document is already 2000x2000 or needs resizing, flattens and converts to sRGB if not already in that profile, runs a Save for Web export with quality set to 60 (which almost always lands under 500KB for clean product shots), writes the file to a delivery folder with the SKU pulled from the original filename using a regex string, and logs each file with a timestamp to a plain text file.

That last part, the log, took me about 20 extra minutes to add to the script. It has saved me from client disputes three times.

The whole script is around 80 lines of JavaScript. It runs 300 files in about 12 minutes unattended. I set it going before lunch, and it’s finished by the time I’m back.

Combining Actions and Scripts: The Hybrid Approach

The most powerful setups I run don’t choose between actions and scripts. They use both. The script handles the file management, folder logic, and conditional decisions. At certain points in the script, it calls a Photoshop action by name using app.doAction("ActionName", "ActionSetName"). The action handles the visual processing steps, because sometimes that’s genuinely easier to build by recording than by writing pixel-level manipulation code from scratch.

For a cosmetics client, my cleanup script calls an action mid-process that runs a frequency separation technique, applies a specific sharpening routine, and adds a branded color grade. That action took 20 minutes to record and tune. Writing the same thing in pure script would have taken hours and been harder to adjust later. The script drives the car. The action plays the music.

Where People Go Wrong Setting This Up

The most common mistake I see, especially from photographers who’ve taught themselves actions, is building automation that assumes everything is the same. The folder structure is always clean. The files are always named correctly. The images are always the right orientation. They’re not. Not in production volume.

Build failure handling from the start. In JavaScript for Photoshop, a basic try/catch block around your main processing loop means that if one file throws an error, the script logs the problem and moves to the next file instead of stopping entirely. I once processed 500 product shots in a single afternoon using a batch system I’d built over the previous weekend specifically for that job. Four files in that run had corrupted metadata and threw errors. The script flagged them, processed the other 496, and handed me a log. Without error handling, I would have come back from lunch to a frozen script and no idea how far it had gotten.

Getting Your First Script Running in Under an Hour

You don’t need to be a developer. Photoshop ships with a Scripts Events Manager under File, Scripts, and an ExtendScript Toolkit (or the newer UXP Developer Tool) that lets you run and debug scripts directly. Adobe also provides a full scripting guide as a free PDF, the “Adobe Photoshop Scripting Guide,” which documents every object, property, and method available.

Start with something small: a script that opens every JPEG in a folder, adds a white 20px border using the Canvas Size dialog, and saves it as a new file with “BORDERED” appended to the filename. That’s maybe 15 lines of code. You’ll learn file iteration, basic document manipulation, and save dialogs all in one pass.

Once that works, the ceiling disappears. I track hours saved in a spreadsheet, because of course I do, and that number sits above 2,400 hours across my consultancy years. The February Tuesday that broke me turned out to be the most productive bad day of my career.

If you’re still recording actions and hoping they’ll eventually be enough, they won’t be. The good news is that what comes next is far less intimidating than it sounds.