A few years back I took on a product photography contract for a mid-sized e-commerce brand. Three hundred SKUs, white background, consistent color profile, two export sizes each. Six hundred files total. The client needed them in 48 hours. I’d built the action sequence over the weekend before, tested it on a sample set, and felt good going into Monday morning. What I hadn’t planned for was how many times I’d need to manually trigger that action, folder by folder, because I’d set it up as a standard batch process through Photoshop’s automation menu rather than as a droplet. It added about 90 minutes of babysitting to a job that should have run itself. That was the last time I made that mistake.

What a Droplet Actually Is (And Why It’s Not Just a Fancy Batch)

Most people who use Photoshop actions know about File > Automate > Batch. You point it at a folder, assign an action, set your destination, and let it run. That works fine. A droplet is the next step up. It’s a standalone executable file, roughly 50-100KB depending on your OS, that encodes your action and all its settings into something that lives on your desktop or in your dock. You drag files onto it. It runs. Photoshop doesn’t even need to be open first.

The reason that matters technically is that a droplet decouples the trigger from the application interface. With a standard batch, you’re always starting inside Photoshop, navigating menus, confirming settings. With a droplet, the application launches if it needs to, processes your files, and you never touch a dialog box. It’s the difference between a tool that assists your workflow and one that disappears into it.

Droplets are also portable within operating systems. If you build one on your machine and your retoucher uses the same OS and has the same action installed, they can run your droplet without ever digging through your action sets. There are cross-platform caveats, specifically that Mac-built droplets need to be rebuilt on Windows and vice versa, but within a single environment they’re consistent and transferable.

Building One: The Exact Steps

Start by making sure your action is polished. Any dialog boxes that pause mid-action for input will also pause the droplet, which defeats the purpose. Record your action with specific values hardcoded wherever possible. If you’re resizing, enter the pixel dimensions directly rather than relying on a percentage prompt.

Then go to File > Automate > Create Droplet. The dialog has five sections you need to think through deliberately.

Save Droplet In: Put it somewhere obvious. I keep mine in a folder called _DROPLETS in my dock on Mac. Naming convention matters here. I use all-caps descriptive names like RESIZE-WEB-1200px-sRGB so I never have to guess what something does six months later.

Play: Select your action set and the specific action. If you have conditional steps or multiple actions that need to run in sequence, build a master action that calls them in order before creating the droplet.

Source: Set this to Files when you want drag-and-drop control. The “Override Action ‘Open’ Commands” checkbox matters if your action includes an Open step. Check it. Otherwise the droplet tries to open the file your action was recorded on, not the files you’re dragging in.

Destination: This is where most people underengineer things. Choose Folder, then point it to a dedicated output directory. Check “Override Action ‘Save As’ Commands” and set your file naming tokens. I typically use Document Name plus a two-digit serial number plus the extension. That gives me clean, sortable output without overwriting originals.

Errors: Set it to “Log Errors to File” and save the log somewhere you’ll actually check it. Silent failures in batch jobs have caused me more re-work hours than any other single thing in my career.

The Real-World Test: 300 Files, One Drag

When I rebuilt my product processing workflow around droplets, I ran the same 300-file test set I’d used to benchmark my earlier batch setup. The batch process, with me supervising it, took 47 minutes including setup time. The droplet ran in 31 minutes, and I spent exactly zero of those minutes in front of the computer. I was on a client call. The log file showed two errors, both files with corrupted metadata that would have caused problems in any workflow. Caught early, fixed in ten minutes.

That’s the part of droplets nobody talks about enough. It’s not just the time you save during processing. It’s the time you recover by not supervising. I’ve been tracking time savings from my automation work in a spreadsheet for years. Droplets account for roughly 400 of the 2,400-plus hours that spreadsheet currently shows. That’s ten full work weeks.

When Droplets Break (And How to Prevent It)

Droplets fail in a few predictable ways. The most common: your action references a specific font, pattern, or layer style that isn’t installed on the machine running the droplet. If you’re distributing droplets to other users, test on a clean machine or document your dependencies explicitly.

The second failure mode is file format mismatch. If your action was recorded on a 16-bit TIFF and someone drops an 8-bit JPEG onto your droplet, steps like certain adjustment layers or blending modes may behave differently or error out. Build in a mode-conversion step at the top of your action if your input files aren’t going to be consistent.

Third, Photoshop updates occasionally break saved droplets, particularly after major version jumps. I rebuild mine at the start of each year as a maintenance habit, the same way I update my drive backup schedule in January. Takes about an hour for a full library refresh and has saved me from mid-job surprises more than once.

The single most valuable thing you can do with a droplet is also the simplest: build it once for a repeatable task, put it somewhere visible, and stop doing that task manually. Every hour you spend automating something you do more than ten times a week pays itself back inside a month.