How to get someone else to strip photo metadata

Every guide on this site, and nearly every guide anywhere, assumes the file is in your hands. You open it, you clean it, you check it, you send it. This page is about the case where that assumption simply does not hold: the photo with your street in it is on someone else's phone, they are the one who will post it, and it may never pass through your possession at all. You cannot clean a file you do not have. What you can do is design the handoff and the instruction — and those are a different skill from operating a tool.

Ready to clean a photo? MetadataWipe processes JPEG and PNG files locally — no account and no server transfer.

Open MetadataWipe tool

The situations are more common than the literature suggests. A contractor photographs work inside your home and posts the results to their portfolio. A relative takes pictures at your house and puts them in a family group. A colleague screenshots something from your machine and attaches it to a ticket. A client sends images to a designer who will publish them. A source has a photograph that needs to be seen but must not identify where it was taken. In every one of these, the person holding the file is not the person carrying the risk, and the person carrying the risk has no hands on the keyboard.

This is the mirror image of the custodian problem covered in should you strip metadata from photos other people send you. There, a file arrives in your possession and you have to decide what you are permitted to do with it. Here, the file never arrives, or arrives only after the damage is already done, and your entire influence is exercised before you touch anything. That changes what "getting it right" even means. Success is no longer a clean file; it is a person completing a step correctly, without supervision, possibly on a device you have never seen, when they are not especially motivated.

Decide where the cleaning should happen

Before writing a single instruction, settle one question: does the file get cleaned at the source, on their device, or at the destination, on yours? People treat this as a matter of convenience. It is actually the main design decision, and the two options fail in opposite directions.

Cleaning at the destination means you ask for the file as it is, and you do the work. Its great advantage is reliability — you have replaced an instruction that may be ignored with an action you perform and can verify. Its limitation is scope. Cleaning at your end governs only the copies that flow onward from you. The original stays on their device and in their sent items, the tagged version has already crossed whatever channel carried it, and if they are also posting the photo somewhere themselves, your clean copy is irrelevant to that audience. Destination cleaning is right when you are the only outbound path that matters.

Cleaning at the source means they do it before the file leaves. Its advantage is that it addresses every copy made from that point onward, including the ones you will never see or hear about. Its cost is that it depends entirely on someone else executing correctly, and you find out about failure late or never. Source cleaning is right when the photo is going to multiple places, most of which are outside your control.

Plenty of real situations call for both: ask them to clean before sending, and clean again when it reaches you. Re-cleaning an already clean file costs nothing, and it converts a single point of failure into two independent ones. If you take only one idea from this page, make it that one — redundancy is cheaper than persuasion.

Why the instruction fails, and how to write one that doesn't

Instructions to non-technical people fail in a small number of predictable ways, and each has a countermeasure.

The word "metadata" triggers disengagement. For most people it is an abstract term attached to no concrete experience, and abstract terms invite deferral. Describe the consequence instead — "the photo has the address saved inside it" — or skip explanation entirely and just name the action.
Steps are a leak. Every additional step in a set of instructions is a place where someone stops. A three-step process is not three times harder than a one-step process; it is more like an order of magnitude, because each step can also be misread. Compress ruthlessly.
They do the right thing to the wrong file. Phones are full of near-duplicates: the burst, the edit, the screenshot of the edit. Naming the photo unambiguously — by subject, not by filename, which they will not read — avoids the most common silent miss.
They substitute something that feels equivalent. Screenshotting the picture, cropping it, or running it through a filter all feel like "doing something to it", and people reach for them. Some of these genuinely do drop tags as a side effect of re-encoding; others do not, and none of them removes what is visible in the frame. Substitution is dangerous precisely because it produces confidence.
They send the original anyway, separately. A clean copy goes to you and the untouched one goes into the group chat an hour later. If the photo matters, say explicitly which copies should exist and which should not.
They report success sincerely and are wrong. This is the one to plan around. "Done" is a statement about their belief, and there is usually nothing in the interface that would have told them otherwise.

A workable instruction therefore has four properties: it names one file, asks for one action, has a visible endpoint the person can recognise as completion, and does not require them to understand why. Where the person's own phone offers a location option inside its normal sharing flow, that is usually the best available route — not because it is technically superior, but because it sits inside a motion they are already making. Whether such an option exists, what it is called and where it appears varies by device, operating system and version, so check on the actual phone rather than describing a menu path from memory. If it is not there, a single link with one sentence of instruction is the next best thing.

Verifying from a distance, and the limits of it

You can verify exactly one thing: a file you hold. If a copy reaches you, inspect it rather than trusting the report — the procedure is in how to verify metadata was removed. What that inspection cannot tell you is anything about the other copies. The version they posted, the version they forwarded, and the original in their camera roll are separate files, and the whole reason you are in this situation is that those files are beyond your reach.

There is also a false positive to guard against. Many sharing and messaging paths re-encode images as a side effect of compressing them, which can drop tags without anybody intending it. So a photo that arrives clean may have been cleaned by the channel rather than by the person — which means the same person will produce a tagged file the next time they use a path that does not re-encode. If you are trying to establish whether someone is reliably doing the step, a single clean arrival is weak evidence. Asking how they did it tells you more than checking the file does.

Where this site's tool fits is narrow. MetadataWipe takes a single JPEG or PNG you choose on the device you are using, runs a quick heuristic scan of roughly the first half-megabyte for EXIF, GPS and PNG metadata markers, redraws the image onto a canvas to produce a metadata-free copy, and returns it with -metadatawipe added to the filename. Everything happens in the browser — the file is not sent anywhere and the download is generated from data already held in the page. That makes it a reasonable thing to hand to someone else, because they do not need an account or an install and nothing about the photo leaves their device. It also sets the boundaries of what you can ask for: one file at a time rather than an album, JPEG and PNG only, no HEIC and no video, a scan that is a quick screen rather than an audit, and no ability whatsoever to reach a file on someone else's phone. If the other person has fifty images, this is the wrong instrument and a batch tool on their own machine is the right one.

Common mistakes and misconceptions

"I explained why it matters, so they'll do it." Understanding and compliance are only loosely related. The person who agrees with you in conversation is still the person who, three days later, shares from a different app without thinking. Design for the forgetful version of them, not the persuaded one.

"They said they removed it." Take this as sincere and unreliable at the same time. Nothing in a typical phone interface confirms that tags are gone, so a confident report is usually based on having performed an action, not on having checked a result.

"Getting them to send me the file solves it." It solves your outbound copies. It does not retract the copy that already crossed a channel, remove the original from their device, or affect anything they post independently.

"A screenshot is good enough." Re-encoding often does drop the tag layer as a side effect, but it varies by platform and method, it is not something either of you can confirm without inspecting the result, and it does nothing about identifying details visible in the picture itself. Relying on a side effect is not the same as performing the step.

"It's one photo, so a one-off ask is enough." If the relationship is ongoing — a contractor, a collaborator, a family member who visits — you are not solving one file, you are solving a recurring event. Changing a default, such as asking them to turn location off in their camera app, does far more work over time than any individual request.

"Cleaning the file handles the privacy problem." It handles the tag layer. A house number on a door, a distinctive view from a window, a reflection or a visible screen are all in the picture, and no metadata tool touches them. When you are briefing someone else, the frame is usually the more important half of the conversation and the easier half for them to act on.

Related guides

Frequently asked questions

Isn't it simpler to ask them to send me the original and clean it myself?

It is simpler, and when the photo is heading to you it is usually the right call, because it replaces an instruction that might be ignored with an action you perform yourself. But be clear about what it buys. Cleaning at your end protects the copy you go on to publish or forward. It does nothing about the copy that travelled to you through a messaging app, an email server or a shared drive, and nothing about the original still sitting in their camera roll. So cleaning at the destination is the right design when you control the only outbound path that matters, and the wrong design when the photo is also going somewhere you do not control — a public post, a group chat, a listing — because in that case the tagged version reaches the audience regardless of how clean your copy is.

How can I tell whether they actually stripped the metadata?

Only by inspecting a file you actually hold, and only for that file. If they send you a copy, you can check it: open it in a viewer, or run it through a scanner, and read the result rather than trusting the reply. What you cannot do is verify the version they posted somewhere else, the version they sent to a third party, or the original still on their device — those are different files and they can differ in exactly the way that matters. There is also a common false negative worth knowing about: many sharing paths re-encode an image in transit, so a photo that arrives clean may have been cleaned by the channel rather than by the person, and the copy they still hold is untouched. Treat a clean arrival as evidence about one file, not as confirmation that the instruction was followed.

What should I do if the person won't take it seriously?

Stop trying to win the argument and change the design instead. Persuasion is the least reliable lever you have, and it fails silently — you never learn that it failed until the photo is public. The more durable moves are structural: take over the step yourself by asking for the file and doing the cleaning at your end; change the route so the photo passes through a path that re-encodes it; reduce the stakes by asking for a different photo, a cropped one, or one taken somewhere that does not matter; or turn off the source of the tag rather than the tag, by asking them to disable location for their camera app so the next batch is clean without anyone having to remember anything. If none of those is available and the photo genuinely matters, the honest position is that you do not control this and should plan for the tagged version existing.

What single instruction works best with someone non-technical?

Ask for one concrete action with a visible endpoint, and name the file. Something like: send me the photo of the kitchen, and before you do, open your phone's share options and turn off location if it offers that. Avoid the word metadata entirely, avoid explaining EXIF, and avoid giving a list of steps, because every additional step is another place to stop. If the share-sheet route is not available on their device, the fallback that fails the least is a single link with a single sentence: open this page, pick the photo, tap the button, send me the file it gives you back. The reason to prefer an option built into their own phone is not that it is technically superior — it is that it sits inside a flow they are already performing, so there is nothing extra to remember, and the failure mode is a forgotten toggle rather than an abandoned task.

Remove EXIF data, GPS location, and common photo metadata in your browser — one file at a time, before you share it.

Try MetadataWipe free