What to do when someone asks you for the original, unedited photo
Nearly every guide on this site assumes the decision is yours alone: you have a picture, you decide what comes off it, you send it. This page is about the harder moment that sometimes follows — a buyer, an adjuster, an editor, a moderator or a client writes back and asks for the original file, the one you deliberately did not send. That is not a cleaning problem. It is a negotiation, and the file is only part of it.
Ready to clean a photo? MetadataWipe processes JPEG and PNG files locally — no account and no server transfer.
Open MetadataWipe toolThe request arrives in predictable places. A marketplace buyer wants proof the item is yours and photographed recently. An insurance adjuster wants the file as it came off the phone. A publication's picture desk wants the unprocessed frame. A platform appeals queue wants the source image for a copyright or authenticity claim. A client wants the full-resolution original they are paying for. A warranty department, a landlord, a letting agency, a fact-checker, a competition organiser: same shape, different letterhead. In all of them, you have already made a privacy decision and someone has pushed back on it.
Most advice fails here because it collapses into one of two bad answers. Either you send the untouched file and undo the whole point of cleaning it, or you refuse flatly and look evasive in a situation where looking evasive has a cost — a refunded sale, a stalled claim, a rejected submission. The useful move is in between, and it starts by noticing that the word original in that message is doing at least four different jobs.
Four different things people mean by "the original"
Unretouched pixels. They suspect the image has been edited in the sense that ordinary people mean: cropped, brightened, blemishes gone, a scratch on the item smoothed over. What they want is the picture as the camera saw it. This has nothing to do with metadata at all, and a metadata-stripped copy answers it perfectly well as long as the pixels were never altered.
The file with its header intact. They want the embedded tag layer: capture date, device, sometimes coordinates. They are testing a claim about when or where or with what, not about the pixels. This is the request that collides directly with what you removed.
The file exactly as it left the device, byte for byte. The strictest version, and the one that matters in formal contexts. Here any re-save is a problem, including a re-save that changes nothing visible, because the point is that the object has not been touched.
Something independently verifiable. They do not want your assertion, they want evidence they can check without trusting you. Increasingly this can mean attached provenance records rather than plain EXIF tags. A wipe-everything re-encode does not preserve records of that kind, since it writes out pixels and nothing else.
These four wants require four different responses, and they are routinely conflated on both sides of the conversation. A buyer who says send me the original usually means the first one and would be satisfied in thirty seconds. An adjuster who says the same words often means the third. Working out which one you are facing is the single highest-value thing you can do, and it is free: ask.
Questions to ask before you decide what to send
- What are you trying to establish? Not what file do you want but what claim are you testing. Nearly every reasonable request reduces to one or two facts, and facts have cheaper answers than files.
- Which specific fields do you need to see? If the answer is the capture date, that is a narrow and often satisfiable ask. If the answer is a vague all of it, you are talking to someone following a script, and scripts can usually be met another way.
- Does it have to be verifiable, or is a stated value enough? This distinction decides whether any partial answer can work at all. Do not guess it; the two paths diverge completely.
- Who else will see the file? A picture desk, a claims system and a public listing have very different onward-sharing behaviour. The relevant exposure is the final audience, not the person typing to you.
- Is a fresh photo acceptable instead? Very often it is, and a photo you take now — to their specification, with location services off — answers the underlying question without disclosing anything about the earlier file or the day it was taken.
- Is there a formal process attached to this? If the words claim, dispute, complaint, investigation or legal appear anywhere in the thread, the calculus changes and preservation comes before privacy.
What a cleaned copy looks like from their side
Being honest about this is the difference between a defensible position and a bad one. A copy produced by a browser tool of this kind is not the original with some fields blanked out. It is a new file: the image is redrawn at its original dimensions and encoded again, so the byte count differs, the compression characteristics are the encoder's rather than the camera's, and the tag layer is simply absent rather than emptied. Anyone who opens it in something that reads metadata sees a header with nothing in it.
An empty header is not incriminating on its own — it is the normal end state of messaging apps, platform uploads, screenshots and gallery re-saves, which is precisely why the reverse inference is unreliable and why our guide on whether you can trust the metadata in a photo someone sent you exists at all. But it does tell an attentive recipient that they are not looking at an untouched file. That has one firm consequence: do not describe a cleaned copy as the original. Send it, say what you did in a sentence, and let them tell you whether it is enough. Almost everyone accepts location and camera details removed for privacy without argument. Almost nobody accepts finding it out for themselves.
Answers that are better than yes or no
Between handing over everything and refusing there is a range of options, roughly in order of how little they disclose.
Answer the question in words. If they need the date, tell them the date. A sentence is a smaller disclosure than a file containing that date plus coordinates, a serial number, software history and an embedded thumbnail. It carries no independent weight, so this only works where a stated value is acceptable — but that is a large share of real requests.
Show a narrow view rather than sending a file. Displaying the one field they asked about, or a cropped screenshot of it, keeps the rest of the header out of the exchange. Remember that a screenshot is itself a new image with its own properties, and that everything visible in the frame goes along with it.
Take a new photo to their specification. Underrated and frequently the best answer. A current photo with today's date, shot to whatever the recipient needs to see, resolves the underlying question while saying nothing about the original file. For marketplace and warranty situations especially, this is usually what the requester would have asked for if they had thought about it.
Send the original, but narrow the channel and the audience. Sometimes the fields really are the point and the answer is to comply. Then the decision moves from whether to to whom, by what route, and with what said about onward use. One named recipient by a direct route is a different exposure from an upload form feeding an unknown system.
Route it through someone whose job this is. Where a professional is already involved — a lawyer, a broker, an agent, an editor — handing the untouched file to them rather than to the counterparty puts a custodian between you and the disclosure, and is standard practice rather than an unusual request.
What none of these options should ever become is the manufactured middle: a re-encoded file with adjusted timestamps, or a cleaned copy presented as untouched. Beyond the ethics, it is fragile — it fails at exactly the moment someone looks closely, which is the moment that matters.
When the answer is that you must not strip anything
There is a category where the advice above inverts. If the photo relates to an insurance claim, a police report, an employment matter, a regulatory complaint, a dispute or litigation, then the original file may need to be preserved intact, and altering or replacing it can create a problem far larger than any privacy exposure it carried. In those situations the correct order is: preserve the original unchanged, keep it somewhere you can produce it, and make any privacy-motivated copy from a duplicate, clearly labelled as such. Our guide on how courts use photo metadata as evidence goes through why examiners care about the header and where stripping becomes the wrong move. Requirements vary by jurisdiction and by the kind of proceeding, this page is a description of how files behave rather than legal advice, and if a preservation duty may genuinely apply you should ask someone qualified where you are before you change anything.
What this tool can and cannot do for this situation
MetadataWipe accepts JPEG and PNG images only, one file at a time, and everything happens in the page in front of you. When you pick a file it runs a quick heuristic scan over roughly the first half-megabyte, reporting whether EXIF-like markers, GPS-like markers or PNG metadata chunks appear to be present — presence only, never values, and a screen rather than an audit. Cleaning redraws the image onto a canvas at its original width and height and exports a new JPEG or PNG, which removes the entire tag layer in one step. The clean copy is saved with a -metadatawipe suffix on the original base name, generated from data already held in the page.
Three consequences follow for the scenario on this page. There is no field-level control, so you cannot use this tool to keep a capture date while dropping coordinates; it is all or nothing. It cannot produce something that looks like an untouched original, and it is not trying to — the output is explicitly a browser-generated copy. And it does nothing to your original file, which stays exactly as it was on your device, so using it never costs you the ability to produce the untouched version later if the conversation turns out to require it.
Mistakes and misconceptions
"They asked for the original, so they need the metadata." Usually they do not. Most requests are about the pixels — is this the actual item, has it been retouched — and a cleaned copy answers them completely. Find out which question you are being asked before you concede anything.
"Sending a cleaned copy and calling it the original is a small fudge." It is the one genuinely risky option on the list, because it is discoverable at the worst moment and it converts a privacy preference into a credibility question. Name what you removed instead; it is a shorter sentence than the excuse.
"Refusing outright is the safe choice." Sometimes it is, but refusal has costs too, and a flat no invites the assumption that the missing fields were damaging. A brief explanation with an alternative attached almost always lands better than silence.
"I can keep the date and drop the location in this tool." Not with this one. A canvas re-encode discards everything outside the pixels at once. Selective editing is a job for a tag utility on your own machine.
"If I strip it now, I have lost the original." No. Cleaning here produces a separate copy and leaves your file untouched. That is worth knowing precisely because it means you can send a cleaned version today without giving up the ability to produce the original if the situation escalates.
"A screenshot of the photo is a safe way to answer." It removes the original header, but it creates a new image, and it carries over everything visible in the frame — surroundings, reflections, on-screen interface, other windows. Visible content is not covered by metadata removal and frequently says more than a geotag would.
"The requester will not know how to check." Reading tags takes one free tool and no expertise, and in the contexts where these requests arise — claims, disputes, picture desks, moderation queues — checking is often routine. Plan for a recipient who looks.
Related guides
See also:
Frequently asked questions
Can the person asking tell that I removed the metadata?
Assume yes, at least to the extent that matters. Anyone who opens the file in a tool that reads tags will see an empty or near-empty header, and an empty header is one of the standard signatures of a file that has been through something rather than coming straight off a camera. Beyond the missing tags, a cleaned copy is a re-encode: the pixels are redrawn and written out again by the browser, so the file size changes, the compression characteristics are those of the browser rather than the camera, and any provenance or edit-history information that was attached to the file is not carried across. None of that identifies which tool you used or proves intent, and a bare header has many innocent causes — messaging apps, platform uploads, screenshots and gallery re-saves all produce one. But it does reliably tell an attentive recipient that they are not holding an untouched original, so the sensible plan is to be straightforward rather than to hope it goes unnoticed.
Should I tell them I stripped the metadata, or just send the file?
Say it, in one sentence, when you send the file. Removing metadata is ordinary privacy hygiene and almost nobody objects to it once it is named; what people object to is discovering it themselves after being handed something described as the original. A line such as this is a clean copy with the location and camera information removed, tell me if you need something more specific costs you nothing and converts a possible credibility problem into a routine caveat. It also tends to surface what the requester actually wanted: if the removed fields were the point, they will say so immediately and you can have that conversation directly instead of through a file they are quietly doubting.
They only need the date the photo was taken. Can I give them that without the file?
Often yes, and it is usually the best trade available. If the request reduces to one fact — when it was taken, which device took it, whether it has been retouched — then supplying the fact is a smaller disclosure than supplying a file that contains the fact plus coordinates, serial numbers, software strings and an embedded thumbnail. You can state the date in writing, or show the relevant field on screen and share only that view. Two cautions. A value you report yourself carries no independent weight, so if the recipient needs something verifiable rather than something asserted, this route will not satisfy them and pretending otherwise wastes both parties' time. And in formal matters — claims, disputes, anything a third party may later examine — a summary is not a substitute for the original file, which should be preserved unaltered regardless of what you choose to send.
Can MetadataWipe give them a copy that keeps the date but drops the location?
No. This is worth being exact about, because selective disclosure is the natural thing to want here and this tool cannot do it. MetadataWipe works on JPEG and PNG images, one file at a time, inside your browser. It cleans by redrawing the image onto a canvas at its original width and height and exporting that as a new JPEG or PNG, which means everything outside the pixel data goes at once: coordinates, capture date, device make and model, software strings, embedded thumbnail, colour profile and any other attached records, with no field-level choice. The before-and-after check it shows is a heuristic scan of roughly the first half-megabyte of the file that reports whether EXIF-like markers, GPS-like markers or PNG metadata chunks appear present — it is a screen, not an audit, and it never displays field values. If your situation genuinely requires keeping one tag while removing another, you need a tag-editing utility on your own machine rather than a wipe-everything browser tool, and you should keep the untouched original either way.
Remove EXIF data, GPS location, and common photo metadata in your browser — and keep your original file exactly where it is.
Try MetadataWipe free