EXIF and IPTC Metadata: What to Strip Before Delivery

What's actually riding inside the file

Two separate metadata standards travel inside a typical JPEG or TIFF, and they get lumped together in conversation even though they come from different eras and do different jobs.

EXIF (Exchangeable Image File Format) is written by the camera at capture. It's a fixed set of technical fields the camera fills in automatically — you never typed any of it, and most of it can't be turned off from a camera menu even if you wanted it gone.

IPTC is older than EXIF — it predates digital cameras entirely, built in the 1990s for newsrooms moving wire photos between agencies, where a caption and a byline had to travel with the image or the photo was useless to an editor on the other end. That history is still visible in the field names: byline, credit line, special instructions. Photoshop, Lightroom and most DAM tools write into these same IPTC fields today when you fill in a caption or a keyword panel, decades after the standard was written for a very different pipeline.

A third block, XMP, sits alongside both in modern files as Adobe's newer, more flexible container, and in practice it mirrors a lot of the same IPTC fields rather than replacing them — which is why the same caption can sometimes show up twice under different panel names in the same editor.

None of this is hidden or encrypted. Any free EXIF viewer, or a right-click "Get Info" on most operating systems, reads all of it in seconds.

The fields that identify you, not just the shot

Most EXIF fields are harmless technical trivia — nobody's day gets worse because a client learns you shot at f/2.8. Three fields are different in kind, not degree.

GPS coordinates are the obvious one. A camera or phone with location services on writes the exact latitude and longitude of the shutter press into every frame. For a client gallery delivered from a studio address, that's a home or business address handed to whoever opens the file. For a personal or family session shot at the client's house, it's their address, in a file they may go on to post publicly without ever opening a metadata panel.

The body and lens serial numbers are quieter but longer-lived. Because they don't change between shoots, they're a fingerprint that ties every image you've ever delivered — to every client, across every year — back to the same two pieces of hardware. That's rarely a problem until it is: a dispute over who shot an image, or a leaked file that gets traced back through the serial number embedded in it, are both scenarios where this field is the whole case.

The IPTC caption and keyword fields are the one people don't think about, because they were typed in on purpose — for organization, not for the client. A retoucher who pastes a client's full name and job number into a caption field for their own tracking has written it into every copy of the file that goes out afterward, including the one a client forwards to a colleague.

What to strip, and what to keep

Stripping every field indiscriminately throws away metadata that's useful to the person receiving the file. The byline and copyright notice are the reason a photo credits you when it's reused; deleting them doesn't protect anyone, it just makes the file harder to attribute correctly.

The date/time field is worth calling out specifically: it feels like it belongs in the strip pile alongside GPS, but stripping it removes something the client is more likely to want than not — proof of when a session happened, useful for their own records, insurance, or a dispute over turnaround time. Strip location, not time.

The exception: when location is the product

The same logic applies, in reverse, to event and wedding photography delivered to a couple who will post selects publicly. There the GPS tag on a photo taken at a private residence is pure downside — nobody downstream is checking for it, and the couple sharing it to social media has no reason to know it's there.

Where the stripping actually happens

Metadata handling isn't uniform across the paths a file can travel. Re-encoding matters more than intent: a platform that regenerates the image — resizing it, recompressing it, generating a thumbnail — has to decide what metadata to carry forward into the new file, and most default to carrying none of it. A platform that just relays the original bytes carries everything, because there was never a point where a decision got made.

That's why a direct email attachment or a synced folder link (Dropbox, WeTransfer, a shared Google Drive folder) passes every EXIF and IPTC field through untouched — nothing in that path ever re-encodes the file. A review link that serves a generated preview and thumbnail rather than the original upload, as Appruva's share links do, only ever hands the client pixels that were regenerated at upload time, not a copy of the original file's metadata block.

Neither path is metadata-aware in the sense of choosing what to keep. The regenerating path just happens to strip everything by default, and the passthrough path just happens to keep everything by default. If you need specific fields kept — a byline, a copyright notice — through a regenerating path, you write them back in explicitly at export, in your camera's export preset or a tool built for the job (exiftool is the standard command-line one, free, and does both stripping and selective rewriting from a single command).

The practical version of this for a working studio: build the strip into the export step you already do for every delivery, not into a separate pass you have to remember. An export preset that clears GPS and serial number fields while writing your byline and copyright notice back in costs nothing extra to run once it's set up, and it runs the same way whether the file is going to one client or forty. The failure mode isn't forgetting once — it's not having a default at all, so every delivery is a fresh decision someone has to remember to make.

The retoucher handoff is where this actually leaks

The riskiest point for metadata isn't the client delivery — it's the round trip through a retoucher, because that's where files pass through the most hands before anyone hits export. A file opened, marked up and re-saved multiple times can accumulate an editing-software history, a caption someone typed for their own tracking, and keywords from a DAM system, none of which anyone meant to include in what eventually reaches the client.

The same discipline that keeps a freelance retoucher's access scoped and revocable is worth applying to what travels with the file itself: know what's in the caption and keyword fields before the final export, not after a client asks why their internal job number is visible in a photo's properties panel. And because knowing which version is current already means treating each round as a distinct file rather than an overwrite, that's also the natural point to decide, per round, what metadata that round's export should carry — rather than inheriting whatever a Photoshop save happened to leave behind three rounds ago.