The Problem Nobody Talks About Until It’s Too Late

Last spring I delivered 340 product images to an e-commerce client, all exported through a Photoshop action I’d built specifically for their spec sheet. Correct color profile, correct resolution, correct file naming convention. Looked perfect on my end. Their web platform read 60 of them as oversized on upload, and their dev team spent two hours troubleshooting something that turned out to be a metadata issue I hadn’t accounted for. The images were technically correct. The export workflow wasn’t.

That kind of invisible failure is exactly what makes export workflows worth taking seriously. It’s not glamorous work. Nobody’s writing blog posts about the thrill of choosing between Baseline and Progressive JPEG encoding. But after 15 years moving through commercial studios and now running my own post-production consultancy, I can tell you that export is where a lot of otherwise excellent work falls apart, and where a well-built action can save you from ever having to think about it again.

What’s Actually Happening When Photoshop Exports a File

Most people treat File > Export > Export As like a save dialog. It isn’t. When you export a JPEG, Photoshop is making a series of encoding decisions: chroma subsampling, Huffman table optimization, metadata stripping (or not), and color profile embedding (or not). Each of those has downstream consequences.

For web delivery, sRGB is the correct color space. If you’re exporting in Adobe RGB and the receiving browser or platform doesn’t color-manage correctly, your blues go slightly purple and your reds go slightly orange. Not enough that a client notices on first look. Enough that it quietly bugs them and they can’t tell you why. I’ve seen this cause two rounds of unnecessary retouching because the photographer and the art director were looking at the same file on different monitors with different color management behaviors.

For print or ad agency handoffs, the conversation flips. Untagged CMYK files or incorrectly converted profiles are a pre-press nightmare. When I’m delivering to an agency for offset print, I export tagged CMYK with the profile embedded, 300 PPI minimum, saved as TIFF with LZW compression, not ZIP. ZIP is technically smaller, but LZW is more universally compatible across older pre-press workflows, and I’d rather send a slightly larger file than get a call at 11pm from a print shop.

Building an Export Action That Actually Covers the Spec

The way I build export actions for client deliveries is to start from the destination, not the file. Before I write a single step, I ask: where is this file going, who is opening it, and what system is ingesting it?

For a standard e-commerce web delivery, my action runs through this sequence: flatten image, convert to sRGB (Edit > Convert to Profile, Relative Colorimetric intent, Black Point Compensation on), run a File > Export > Export As at Quality 8 (not 10, not 12 - 8 is the sweet spot for file size vs. perceived quality at screen resolution), strip all metadata except copyright, and export to a folder named with the client code and date. That last step, the naming convention, gets baked into a Batch action that runs across an entire folder. Quality 8 in Photoshop’s JPEG scale gives me files in the 300-500KB range for a 2000x2000px image, which clears most platform upload limits without aggressive compression artifacts.

For print deliveries, I keep a separate action set entirely. TIFF, 300 PPI, embedded profile, 16-bit where the client’s spec allows for it. File sizes get large fast at 16-bit TIFF, often 80-150MB per file for large format work, so I also have a step that auto-creates a low-res JPEG preview at 1000px on the long edge and Quality 6. Clients get both: the delivery file and the proof, named identically except for a “_PROOF” suffix. Eliminates a lot of back-and-forth.

The Afternoon I Actually Calculated What This Was Worth

I mentioned that I track the hours my actions save me. I started the spreadsheet as a joke, honestly, a way to justify the weekend I’d spent building out a batch system. That system let me process 500 product shots in a single afternoon for a client whose studio had fallen behind before a major catalog launch. Shooting was done. Every image needed background cleanup, color correction to a reference, resizing to three different output specs, and renamed file delivery. The batch ran for about four hours while I did other billable work.

Without automation, that job at even a conservative 3 minutes per image across all steps is 25 hours of manual labor. My rate at the time was $90/hour. That’s a $2,250 gap between doing it the slow way and doing it the right way. I’ve since crossed 2,400 hours saved in the spreadsheet. The math on that is uncomfortable to look at directly.

The point isn’t to brag about efficiency. The point is that export isn’t an afterthought you handle at the end of a job. It’s a decision you make at the beginning, when you’re building the workflow, before you’ve touched a single file.

The Metadata Problem That Bit Me (and How to Fix It)

Back to that metadata issue from the spring. What happened was that my action was preserving EXIF data including a “Software” field that the client’s DAM system flagged as non-compliant. The fix took about 90 seconds once I understood it: in Export As, there’s a Metadata dropdown. I had it set to “All.” It should have been set to “Copyright Only” for that client’s delivery spec.

Now I build a metadata audit into every new client onboarding. I ask for a sample file their system has ingested successfully, open it in Photoshop, and check File > File Info to see exactly what metadata their pipeline expects or tolerates. Then I build that profile into the export action from day one. It’s an extra 15 minutes of setup that has never once caused a problem since I started doing it.

The most expensive export error is the one you don’t find until after delivery. Build your action for where the file is going, not just for how it looks on your screen, and you’ll spend a lot less time explaining yourself to developers at 11pm.