A few years back I had a client send over 500 product shots on a Friday afternoon. New colorway launches for an e-commerce catalog, all needing the same sequence: resize to 2000px on the long edge, convert to sRGB, sharpen with a specific Smart Sharpen value, save as JPEG at quality 9 into a web-ready folder. Same thing, 500 times. I had a weekend. I also had a droplet I’d built in about 40 minutes the month before.

I dragged the folder onto a tiny icon sitting on my desktop, walked away, made coffee, and came back to 500 processed files. That’s not an exaggeration or a setup to sell you something. That’s just what droplets do when you’ve set them up properly.

What a Droplet Actually Is (And Why It’s Different From Batch)

Most people who use Photoshop actions know about File > Automate > Batch. You point it at a folder, pick an action, let it run. Droplets are the next step up, and the distinction matters. A droplet is a standalone executable file, generated by Photoshop, that contains an action baked right into it. You drag files or folders onto its icon from your desktop or file manager and it fires Photoshop, runs the action, and processes everything without you touching the Photoshop interface at all.

Under the hood, Photoshop compiles your action’s steps into a small application file (.exe on Windows, no extension on Mac). When triggered, it launches Photoshop in the background, or uses a running instance, applies every step in your action sequence using the same engine as a manual Batch command, and handles file management based on rules you set at creation. The practical difference is portability and accessibility. You can drop a droplet into a shared folder on a network drive and a retoucher who has never opened Photoshop’s Automate menu can use it correctly every time.

Building the Droplet: Settings That Actually Matter

Go to File > Automate > Create Droplet. The interface looks almost identical to the Batch dialog, and that’s intentional. Here’s where most guides skim over the details.

Choose Action: Pick the action set and the specific action. If your action has a Stop step asking for user input, either remove it or check “Suppress Action Steps That Display Messages” or the whole thing will pause and wait for someone to click OK 500 times.

Destination: This is the one that causes the most problems. “Save and Close” overwrites your originals. Never use this unless you’re working from copies. “Folder” lets you specify an output directory and, critically, lets you use File Naming tokens to build structured filenames automatically. For product work I typically use Document Name + two-digit serial number + extension. That gives me clean, predictable output like “jacket-blue-01.jpg” without any manual renaming.

File Type Overrides: If your action includes a Save As step, check “Override Action ‘Save As’ Commands.” This forces the droplet to use your Destination settings instead of whatever path was hardcoded when you recorded the action. Without this, files can end up saving to wherever you happened to be working when you recorded the action originally, which is chaotic.

Error Handling: Set this to “Log Errors to File.” If one image in a batch of 300 causes a problem, you want a text log telling you which file failed and why. You don’t want Photoshop to stop the entire run to show you a dialog box.

Organizing Droplets So You Can Actually Find Them

I keep a folder called “Droplets” inside my main post-production toolkit directory, and inside that I’ve got subfolders by client type: Ecommerce, Advertising, Internal. Each droplet has a naming convention that tells me the action it runs and the output format, something like “Ecom-WebResize-sRGB-q9.app.” I color-code the icons on Mac using the label system in Finder, green for delivery-ready outputs, orange for intermediate processing steps, red for anything destructive that works from originals.

This sounds like overkill until you’re on a deadline and someone sends a folder of raws and you need to know in three seconds which droplet handles your client’s specific delivery spec.

The One Time a Droplet Broke Everything (And What I Learned)

I recorded an action on a 16-bit TIFF workflow, built a droplet from it, and then tried to run it against a folder of 8-bit JPEGs. Several of the steps failed silently, including a Curves adjustment that was mode-dependent. The droplet kept running, logged zero errors because the steps didn’t technically throw exceptions, and I ended up with 120 files that looked almost right but had clipped highlights.

That cost me about two hours of checking and re-running. Now I build and test every droplet against the exact file type and color mode it’s designed for, minimum five test files, before I put it anywhere near a real job. I also put a dummy Stop step at the beginning of any action I’m testing so I can confirm it’s running the right action before it touches anything.

The lesson isn’t that droplets are fragile. It’s that they’re only as reliable as the action underneath them, and actions need to be tested under the same conditions they’ll run in production.

When Droplets Pay Off Versus When They Don’t

Droplets make sense when you’re processing at least 20+ files with the same specs and you expect to repeat that job type more than once. For a one-time batch of 15 images, the Batch dialog is faster to set up. Droplets earn their time investment on repeated workflows: a weekly e-commerce resize, a recurring agency deliverable, a standard web-to-print conversion you run every few days.

If you’re already using actions and you haven’t built a single droplet, you’re leaving real time on the table. Not in a vague, motivational-poster sense. In a “I have a spreadsheet that says I’ve saved over 2,400 hours since 2012” sense. Build the droplet once, test it properly, name it so you know what it does, and put it somewhere you’ll find it. That’s the whole thing.