Should You Strip Metadata From Photos Other People Send You?

Almost all metadata advice — most of this site included — is written for the sender. You are holding your own JPEG, it has your home GPS and your camera serial in it, and the correct action is obvious: wipe it before it leaves. There is exactly one party with an interest, and that party is you.

Now flip it. A tenant emails you six photos of a leaking ceiling. A customer attaches a screenshot to a support ticket. A contributor sends images for your newsletter. A source sends a photograph they should probably not have taken. Those files are now in your inbox, your ticket queue, your shared drive. The GPS in them is somebody's apartment. The timestamp is somebody's alibi or somebody's shift. And the question you actually face is not how do I strip this, because that part takes ten seconds. It is am I allowed to, and should I?

That is a harder question than the sender's version, because both answers have a failure mode. Strip it, and you may have quietly destroyed the provenance that an adjuster, an editor, or a court was going to rely on. Keep it, and you have made yourself the custodian of location data about a person who never once thought about EXIF. Neither the "always wipe everything" reflex nor the "never touch what you were given" reflex is right on its own. What you need is a rule for deciding which situation you are in.

Work out which custodian you are

Nearly every received-file situation collapses into one of three roles, and each has a different default.

The conduit. You are going to pass the image onward to a wider audience: a moderator reposting a member's photo, a property manager putting tenant-supplied pictures into a public listing, a marketer using a customer photo, a charity publishing images a partner org collected. You do not need the metadata and the eventual audience definitely does not. Default: strip the outbound copy.

The evaluator. You are being asked to judge the file itself — a claims handler checking whether damage predates a policy, a fraud reviewer, a journalist verifying a tip, a moderator assessing whether an image is original or lifted. Here the metadata is the work. Default: do not strip anything, and quarantine the file so nobody else does either.

The storer. You merely end up holding it: HR with applicant headshots, support with attachment history, a volunteer coordinator with a folder of event photos. Nobody downstream is relying on provenance, but the files sit there accumulating. Default: minimise how long you keep them, and clean anything that gets circulated internally.

Most real leaks happen because someone in the conduit role behaved like a storer — they filed the image away and then, months later, published it byte-for-byte exactly as it arrived.

A decision checklist before you touch a received file

1. Does anyone downstream rely on this file's provenance? If the answer is yes, or if the answer is "I don't know yet," do not strip the only copy you have. Uncertainty argues for keeping, not cleaning.
2. Is a dispute foreseeable? Obligations to preserve material differ by jurisdiction and circumstance, and nothing here is legal advice — but if a complaint, claim, or investigation is plausibly coming, treat the received file as untouchable and ask someone qualified before deleting from it.
3. Keep two copies with two distinct jobs. The file exactly as it arrived goes in restricted storage. A cleaned derivative is what circulates. This is the same two-copy discipline the workplace confidentiality guide describes for internal photos, applied to material you did not create.
4. Strip at the publish boundary, not at intake. Cleaning on receipt is irreversible and premature. Clean the copy at the moment it is about to reach a wider audience.
5. Screen it rather than trusting the sender. Drop the JPEG or PNG into the tool and read the check panel. Assume nothing was removed, because usually nothing was.
6. Look at the pixels, not just the header. A house number, a school uniform, a reflection in a window, a name badge, a visible screen — no metadata tool touches any of that. Stripping EXIF from a photo that shows someone's front door achieves very little.
7. Fix the filename. IMG_20260914_112233.jpg is harmless. rachel-m-unit-4b-claim-8871.jpg travels with the file through every system you forward it into, and cleaning the header does nothing to it.

Where recipients actually leak

Republishing a member's photo to an official account. The member posted it to a small private group. You put it on the org's public feed. Depending on the path, the original headers can survive — and you have widened the audience for coordinates the person only ever shared with forty people.

Attaching a customer's screenshot to a public tracker. Support receives an image privately and then pastes it into an issue that is world-readable. The escalation, not the intake, is the disclosure.

Publishing a source's file unmodified. This is the one with the worst downside. A photograph sent by someone taking a risk can carry a device serial, a precise timestamp, and a location that narrows the set of people who could have taken it. Publishing the bytes you were sent is a well-understood way for a source to be identified. Rebuild a clean derivative and publish that.

Forwarding an email attachment. Re-attaching does not launder anything. The bytes are copied verbatim, headers included.

Mistakes recipients make

Cleaning the original instead of a copy. The single most expensive error on this page, because it is the only one you cannot undo.

Assuming the delivery path cleaned it. Some paths re-encode and drop most headers; others hand over the file untouched, and the same app can do both depending on whether the image was sent as a photo or as a document or file. "It came through a messaging app" tells you almost nothing.

Believing the sender. People sincerely report having removed metadata after cropping, renaming, or resaving — none of which reliably does it.

Treating stripping as anonymising. Removing GPS from a photo of an identifiable person in an identifiable place protects roughly nobody. Headers are one layer.

Stripping something you were handed as evidence. If the file arrived because of a dispute, the metadata is very likely the point. How courts use photo metadata as evidence covers why those tags carry weight and why altering them is treated differently from cleaning your own photos before posting.

Related guides

See also:

• Photo metadata and workplace confidentiality
• How courts use photo metadata as evidence