There’s a file on my desktop called “DO NOT USE - OLD PRESETS GRAVEYARD.” It contains 47 presets I built between 2009 and 2016 that I eventually stopped trusting, each one a small monument to a lesson I learned the hard way. A sharpening preset that looked perfect on my old 27-inch iMac and then destroyed edge detail on every asset I sent to a client’s retoucher in New York. A batch-resize action that worked flawlessly on JPEGs and silently corrupted embedded ICC profiles in TIFFs. A color grade built for one studio’s lighting setup that contaminated three months of work for a different brand before anyone caught it.

Custom presets are one of the highest-leverage tools in Photoshop, and they’re also one of the easiest to build badly. After 15 years working in commercial photography, I have strong opinions about why.

What a Preset Actually Is (And Why Most People Build Them Wrong)

When you save a preset in Photoshop, whether it’s a tool preset, a color swatch set, an adjustment layer default, or a full recorded action, you’re capturing state, not intent. Photoshop doesn’t know what you were trying to accomplish. It just writes down what you did.

That distinction matters enormously in production environments. A Curves adjustment that brings up shadow detail on a RAW file processed in Adobe Camera Raw with a specific input profile will do something completely different to a flat TIFF that arrived from a scanner, or a JPEG a client exported from their phone. The preset didn’t change. The image did. Photoshop doesn’t bridge that gap for you.

This is why I always build presets with a defined file spec in mind. Not “for product photography.” For product photography at 3000x3000px, Adobe RGB 1998, 16-bit, shot under controlled strobe lighting against a white sweep. That’s a preset. The broader version is a liability.

The Anatomy of a Preset That Survives Real Production

Every stable preset I use has three components I’m deliberate about: a conditional trigger, a neutral starting point, and a destructive-last policy.

The conditional trigger means the preset only fires on files that match its intended input. In Photoshop actions, you can use conditional steps (found under the Insert Conditional option in the Actions panel menu) that check things like document color mode or orientation before proceeding. I use these constantly. A simple mode check, “if not RGB, stop and alert,” has saved me from applying an RGB-specific sharpening algorithm to a CMYK press file more times than I want to admit.

The neutral starting point means that wherever possible, I’m building presets on top of Smart Objects with non-destructive adjustment layers. The final flatten or rasterize step happens last, and it’s always a separate action step I can pause before executing. This costs maybe 200-400MB of extra working file size on a complex composite, but it means I can re-enter any part of the pipeline cleanly.

Destructive-last is exactly what it sounds like: any irreversible operation, sharpening, flattening, converting to 8-bit, saving as JPEG, happens at the end of the action sequence, never in the middle. If the action fails or produces something unexpected, I still have a recoverable file.

The Spreadsheet I Keep That Most People Find Ridiculous

I’ve been tracking time savings from my automation work since about 2017. I use a color-coded Google Sheet (of course) with columns for the preset name, the task it replaces, the approximate time per manual execution, and the number of times it’s run. The current total is just over 2,400 hours saved.

I bring this up not to brag but because the data consistently shows something counterintuitive: my highest-value presets are not the ones that do the most complex operations. They’re the ones that handle high-frequency, low-complexity tasks with zero errors. My single-step “Export Web Ready” action, which flattens, converts to sRGB, resizes to 2000px on the long edge, sharpens at 120/0.3/0 using Unsharp Mask, and saves as a 90-quality JPEG to a timestamped output folder, has logged more saved hours than any of my compositing actions. It runs maybe 80 times on a busy week. It never fails, because it was built for exactly one use case.

The presets that have caused me problems are the ones I built while tired, trying to handle too many variables at once, telling myself I’d “refine it later.”

How to Actually Test a Preset Before It Goes Into Production

The single biggest mistake I see people make with Photoshop presets is testing them on the same type of file they built them on. That’s not a test. That’s confirmation bias.

Before any preset goes into my production library, I run it against five deliberately awkward files: a landscape-orientation version of what is normally a portrait file, a 72dpi web image when the preset expects 300dpi, a document that’s already been flattened once, an image with a layer mask active (not just present, but actively selected), and a file that’s at 50% of the expected pixel dimensions. If it handles all five gracefully, either by completing correctly or by stopping and giving a clear error, it earns a spot in the library. If it silently produces garbage on any of them, back to the drawing board.

This protocol came directly from an incident early in my consultancy work where a batch action I ran against 220 product images applied a pixel-level crop that was correct at 3000px and visually wrong at 1500px because I’d hard-coded the crop dimensions instead of using percentage-based values. The client noticed before delivery, barely.

Where to Go From Here

The best preset library isn’t the biggest one. It’s the one you’ve actually tested, the one with clearly defined input specs, the one you trust enough to run on 500 files while you’re in a client call and not check until it’s done.

Build fewer presets than you think you need. Build them for exactly one job. Test them until they fail, then fix what failed.