A few years back I had a client, a mid-size e-commerce brand, send over 500 product images on a Thursday afternoon. They needed them web-ready by Monday morning: resized to 1200x1200px, converted to sRGB, sharpened for screen, and saved as optimized JPEGs. Four steps, 500 images. I’d built the action the previous weekend specifically for this kind of job. What I hadn’t built yet was a proper droplet. So instead of dragging a folder and walking away, I was babysitting the batch processor for three hours, restarting it every time a filename tripped something up. That was the last time I ran a job that way.

What a Droplet Actually Is (and Why Actions Alone Aren’t Enough)

Most people who use Photoshop actions know the File > Automate > Batch route. You point it at a folder, pick your action, and let it run. That works, but it ties you to Photoshop’s interface. The batch dialog has to stay open. You have to be there to configure it every time.

A droplet is different. Photoshop compiles your action into a small executable file, usually sitting right on your desktop or in a project folder. You drag images or entire folders onto its icon, and it processes them. That’s it. You can do this while Photoshop is already open with another document. You can hand the droplet to a junior editor or a production assistant and they don’t need to understand actions at all. On a Mac, droplets even work across OS versions if you rebuild them occasionally. They’re portable, repeatable, and self-contained in a way that the batch dialog simply isn’t.

Under the hood, a droplet is essentially a compiled script that calls Photoshop’s batch processing engine with all your settings pre-baked. The action, the source behavior, the destination folder, the file naming convention, and the error handling are all locked in ahead of time. That’s what makes them reliable at scale.

Building a Droplet That Doesn’t Break at File 47

Go to File > Automate > Create Droplet. The dialog looks almost identical to the Batch dialog, which is intentional. Here’s how I configure mine for production work.

Set the action first. Make sure it doesn’t include an Open step or a Save/Close step unless you specifically need to control those. Photoshop handles file opening and saving through the droplet settings, and having those inside the action as well creates conflicts.

For “Play,” I keep “Override Action Open Commands” checked. For destination, I almost always use a subfolder rather than saving over the source files. I name it something like “_processed” so it sits alphabetically clean in the directory. File naming matters more than most people think: I use a two-digit serial number plus the document name, which keeps things sortable and avoids overwrites when I’m processing multiple batches into the same folder.

Error handling is where a lot of droplets fall apart. Set it to “Log Errors to File” rather than stopping on each error. If a CMYK file sneaks into your sRGB batch, you don’t want the whole process to halt at image 200. You want it to finish and leave you a log so you can handle the exceptions manually. Save that log to the desktop, not inside the processed folder, so it doesn’t get swept up in any subsequent file moves.

The Setting Most Tutorials Skip

Photoshop’s default behavior when running a droplet is to process images in the color space of each file. If your client is sending you a mix of sRGB, Adobe RGB, and files with no embedded profile, this will create inconsistent results silently. No error, no warning, just subtly different output.

Fix this inside the action itself, not in the droplet settings. Add a Convert to Profile step as the first step in your action, set to sRGB IEC61966-2.1 using Perceptual rendering intent. Now every file gets normalized at the start of the pipeline before anything else touches it. This is especially important for e-commerce work where color consistency across a product catalog is non-negotiable.

Cross-Platform Droplets and the One Gotcha

If you work in a mixed Mac and Windows studio, droplets aren’t directly cross-compatible. A droplet built on a Mac is an application bundle. On Windows it’s an .exe file. You can’t drag a Mac droplet to a Windows machine and have it run. What you can do is export the action as a .atn file, move it to the other OS, and rebuild the droplet there in about two minutes. I keep both versions in a shared Dropbox folder labeled by date so everyone on a project is running the same version.

The one gotcha I’ve hit multiple times: if you move a droplet to a different folder, or rename any folder in its output path, it breaks. The destination path is hardcoded at compile time. When I set up a project folder structure, I build the droplet last, after all the folders are in their final locations. I also keep a text file next to each droplet with the build date and the name of the action it’s based on, because six months later I never remember which action version is inside.

Why I Rebuilt My Entire System Around These

I currently track my automation time savings in a spreadsheet. I know that sounds excessive, but across 15 years of studio and consultancy work, that number is sitting above 2,400 hours. A significant portion of that came from the shift from manual batch processing to droplet-based workflows. The difference isn’t just speed. It’s that I stopped being a bottleneck. I can hand a droplet to someone with no Photoshop training and trust the output.

Build your action first, test it on 10 files manually, then compile the droplet. That order matters, because fixing a broken action after it’s baked into a droplet means rebuilding the droplet from scratch.