A few years into running my own post-production consultancy, I had a client send over 500 product images the Friday before a campaign launch. The brief was straightforward: standardize white balance, apply a branded tone curve, sharpen for web, flatten, export as sRGB JPEGs at 1200px on the long edge. Same thing, 500 times. I had the action built already. What I didn’t have was any interest in manually running it file by file, or even babysitting a batch process through the weekend.

What I used instead was a droplet. I dropped the folder on the icon, went and had dinner with my family, and came back to 500 finished files. That’s not magic. That’s understanding what a droplet actually is and how to build one that doesn’t break.

What a Droplet Is Doing Differently Than a Batch Process

Most Photoshop users know about File > Automate > Batch. Droplets are essentially a packaged, portable version of that same system, except instead of living inside Photoshop’s menu, they live on your desktop or in a folder as a standalone executable. You drag images or folders onto them. They run. No menus, no Photoshop navigation required.

Under the hood, a droplet is storing your action name, your source handling instructions (how to handle subfolders, what to do with open files, whether to suppress color profile warnings), and your destination and file naming rules. All of that gets compiled into a small application file, typically under 100KB, that calls Photoshop and feeds it instructions the moment something lands on it.

The practical difference between a droplet and running a batch manually is friction. Friction compounds. When I track time saved by automation (and yes, I do track it, in a spreadsheet that currently sits at over 2,400 hours), friction is the hidden category. It’s not just the processing time, it’s the opening menus, the choosing folders, the clicking okay. Droplets eliminate that entirely.

Building One That Won’t Break on File 47

The failure point I see most often is people building a droplet from an action that wasn’t designed for automation. If your action includes a step that opens a dialog box and waits for input, it will pause on every single file unless you’ve told Photoshop to suppress dialogs. When you create the droplet (File > Automate > Create Droplet), there’s a checkbox: “Suppress Action Playback Errors.” Use it only after you’ve tested. Suppressing errors during testing means you won’t catch the spot where your action fails silently.

The settings I use for almost every production droplet: source set to “Folder,” subfolders included, open files skipped. Destination set to a specific output folder I’ve pre-created, never “Save and Close” on the originals. File naming using a custom sequence: original filename plus a two-digit sequence number plus the export date in YYYYMMDD format. That naming convention means I can sort by date, trace a file back to its source, and avoid any overwrites. Under “File Type,” I save as JPEG at quality level 10 (not 12, because the file size difference between 10 and 12 is significant, often 40 to 60 percent larger, with virtually no visible difference at web resolution).

Color Profiles and the Silent Corruption Problem

Here’s something that burns people: color profile mismatches don’t throw errors. They just quietly shift your colors. When I’m building a droplet for a client whose deliverables need to be sRGB, I include a “Convert to Profile” step inside the action itself, not just in the export settings. The action converts to sRGB IEC61966-2.1 explicitly, with relative colorimetric rendering intent, and then the droplet’s save settings reinforce that. Two layers of enforcement.

The “Suppress Color Profile Warnings” checkbox in the droplet creation dialog is essential for unattended runs. Without it, Photoshop will stop and ask you what to do every time it hits a file with an embedded profile that doesn’t match your working space. For a 500-file run on a Friday night, that is not a theoretical problem.

Cross-Platform Droplets and Why I Keep Two Versions

Droplets are platform-specific. A droplet built on a Mac won’t run on Windows, and vice versa. I learned this the hard way when I sent a client a droplet as part of a deliverable package and they were running Windows. Now I keep two versions of every production droplet I build, clearly labeled “mac” and “win” in the filename, stored in the same project folder. Building both takes maybe three extra minutes. The Windows version gets built on a VM I keep specifically for compatibility testing.

One thing that trips people up on the Windows side: if you move the droplet to a different machine or a different drive path, Photoshop might lose the reference to the action set. The fix is to open the droplet in Photoshop (drag it onto the icon, not onto an open document), let it rebuild the batch dialog, re-link the action, and save it again. It takes 30 seconds once you know that’s how it works.

When the Setup Cost Isn’t Worth It

I’ll be honest about the math. Building a solid, tested droplet, including writing the underlying action cleanly, usually takes me 30 to 45 minutes. That means for anything under about 20 to 30 files, you’re not saving time, you’re spending it. The value is in repeatability. If I know I’ll run this same process again, even twice more, the droplet pays for itself. If it’s genuinely a one-off job, I run the batch manually and move on.

The other case where I skip the droplet is when the files are inconsistent enough that I need to review each one anyway. Automation is a force multiplier, but only when the inputs are predictable. For catalog work and e-commerce where file specs are locked, droplets are essentially mandatory. For editorial or fine art work where every image needs individual attention, they’re not the right tool.

The single best thing you can do with any action you’ve built more than twice is turn it into a droplet, test it on ten files, then leave it on your desktop and forget it was ever a manual process.