Can you trust the metadata in a photo someone sent you?

The situations are ordinary. A marketplace seller sends a picture of the item and says it was taken this morning. A contractor sends photographs as proof the work was finished. A landlord or host sends listing images that may or may not be from the current decade. Someone in a dispute — a neighbour, a customer, a former partner — produces a photo as support for their version of events. A person you have not met sends a picture of themselves. In each case you are not protecting anything; you are evaluating something, and the cost of getting it wrong runs the other way. On the rest of this site the failure mode is a leak. Here the failure mode is a confident false conclusion: you believe a photograph you should have doubted, or you accuse someone based on a field that never meant what you thought it meant.

That reversal matters because the reasoning habits are different. Removing metadata is a procedure, and procedures can be followed. Reading metadata is inference, and inference goes wrong quietly. The rest of this page is mostly about the ways it goes wrong.

What a metadata field actually is

Start from the right mental model, because most bad conclusions come from the wrong one. People treat a metadata field as an observation — a record of what happened, made by the file itself. It is not. A field is a claim written by whatever software last saved the file, derived from whatever that software had available at the time, on a device configured by a person. That is the whole of its authority.

There are three separate reasons the claim can fail to match reality, and they are worth keeping apart because they call for different follow-up questions.

• It may never have been accurate. A camera writes the time its own clock reports. Clocks drift, get set wrong, sit in the wrong time zone, or stay on the zone of the place the device was last configured rather than the place it currently is. Location comes from whatever positioning the device managed at that moment, which can be approximate, stale or missing.
• It may have been changed afterwards. Metadata is ordinary data in the file and, in the general case, nothing about it is tamper-evident — there is no signature a normal viewer checks, and no neutral party vouching for the values. Editing tags is not a specialist forensic capability; a variety of widely available software writes them routinely. Schemes for cryptographically signed provenance exist precisely because unsigned tags carry no assurance, but whether a particular photo carries such a record, and whether your software can validate it, is something to establish rather than assume.
• It may have been discarded in transit, silently. Plenty of ordinary handling drops the tag layer as a side effect of recompressing an image, and nothing in the resulting file records that this happened or what used to be there.

Put those together and you get the core asymmetry of reading someone else's photo: the presence of a field is weak positive evidence, because it could have been written by anyone, and the absence of a field is almost no evidence at all, because it disappears for a dozen innocent reasons.

Why an empty header proves nothing

The most frequent misreading, by a wide margin, is treating a bare file as an admission. There's no EXIF on this — they've scrubbed it — what are they hiding? Almost every step of that chain is unsound.

Photos arrive stripped all the time without anyone intending it. Many platforms re-encode images when they are posted, so a picture saved back down from a public post is usually a derivative rather than the original — the habits vary by service and change over time, which is the subject of which social platforms strip photo metadata automatically. Messaging apps frequently compress. A screenshot of a photo is a new image with the screenshotting device's own minimal record and none of the original's. Re-saving in a gallery or editing app can rewrite the file. Even a file forwarded from a chat rather than pulled from a camera roll may be the compressed copy rather than the source.

And when the removal was deliberate, it still is not an admission about the photo. Stripping metadata before sharing is standard privacy advice — it is the advice this entire site gives — so a person who cleans their photos is displaying a habit, not a motive. Inferring guilt from a clean file is inferring guilt from cautiousness.

What an empty header genuinely tells you is narrower and still useful: you are probably not holding an untouched original. That is a good reason to ask for the original, and a good reason not to build anything on this copy. It is not a finding about the sender.

What the common fields are actually worth

Assuming you do have fields to read, here is a realistic valuation of the usual ones. The pattern to notice is that almost every field is informative about consistency and poor as standalone proof.

• Capture date and time. The device clock's opinion, unverified, with time-zone handling that varies by device and software. Useful for checking whether a set of photos forms a coherent sequence. Not usable as a date on its own, and among the easiest fields to change.
• GPS coordinates. Where the device believed it was. Often the most substantive field present, and still only a lead — accuracy varies, fixes can be cached, and coordinates say nothing about who was holding the camera. A photo taken at an address is not proof the sender lives there, and not proof they took it.
• Camera make, model and lens. Tells you what wrote the file, which is a decent cross-check against a claim about equipment or against other photos from the same person. Says nothing about the operator.
• Body or lens serial numbers. When present, the strongest linking field available: it can tie two files to one piece of hardware. It still links devices, not people, and it is present far less often than people expect.
• Software and editing tags. Evidence the file passed through a particular program — not evidence of what was changed, since resizing, cropping, exporting and colour correction all leave the same kind of trace as a substantive manipulation. Their absence is equally uninformative, since plenty of export paths write nothing. What they do and do not record is covered in can metadata reveal if a photo was edited in Photoshop or Lightroom.
• Embedded thumbnails. Occasionally a real tell, because a preview generated before an edit can survive alongside the edited image. Inconsistent enough that its absence means nothing.
• Dimensions, file size and encoder characteristics. Descriptions of the most recent save, not of the capture. Useful mainly for spotting that a file has been through a pipeline.

A reading discipline

The following sequence is designed to stop the two failure modes — believing a field and over-interpreting its absence.

1. Write down the claim before you look. "Taken yesterday", "taken at this address", "not edited" and "taken by this person" are four different tests with four different answers. Deciding afterwards what the metadata proves is how people end up proving whatever they already suspected.
2. Establish which file you are holding. A copy that came through a messaging app or a social post is a different artefact from the original. If the question matters, ask for the file as it came off the device, sent by a route that does not recompress, and note that the request itself is informative.
3. Look for internal consistency, not single-field truth. Do the various timestamps in the file agree with each other? Does the camera model match what this person plausibly owns or what their other photos show? Does the location fit the time?
4. Compare across several files. A set is much harder to fabricate coherently than one file, and this is where most real discrepancies surface. It is the same property that makes a batch of photos leak more than one photo does, working in your favour for once.
5. Seek corroboration outside the file. What is visible in the frame — weather, seasonal light, signage, a model of car, the state of a building — is frequently more informative and much harder to edit than a tag. So are ordinary non-technical checks.
6. Decide in advance what would change your mind, and accept "cannot tell" as a real, common and respectable result. Most of the time the honest answer to "does the metadata prove this" is no.
7. Do not confront on a field alone. Given how easily timestamps go wrong innocently, an accusation resting on one value is likely to be both wrong and unrecoverable.

One practical caution about handling: preserve the file you were sent. Opening it in some applications, re-saving it, or running it through any processing produces a different file, and if the question ever becomes serious you will want the thing as it arrived. Work on a duplicate.

Where this site's tool fits, and where it does not

MetadataWipe is a removal tool, and it is worth being explicit that it is the wrong instrument for the task on this page. It accepts a single JPEG or PNG at a time. Its built-in check is a quick heuristic scan of roughly the first half-megabyte of the file, reporting only whether EXIF-like markers, GPS-like markers or PNG metadata chunks appear to be present — it displays no values, so it cannot show you a date, a coordinate pair or a camera name. Cleaning works by redrawing the image and generating a fresh copy with -metadatawipe added to the filename. Everything runs in the browser; the file is not sent anywhere and the download is produced from data already held in the page.

For the receiving end, that means two things. First, if you want to read values rather than detect their presence, you need a metadata viewer rather than a stripper. Second, and more importantly: do not clean a file you are evaluating. The cleaned output is a newly generated image, and what it discards is precisely the material you were examining. If you later decide the cleaned copy is the one you want to forward on — because you are republishing the photo and do not want to pass someone else's location onward — that is a separate, legitimate step to take on a duplicate, after you have finished looking.

Common mistakes and misconceptions

"No metadata means they scrubbed it." It usually means the file has been through a normal pipeline. And even deliberate removal is ordinary privacy behaviour, not a signal about the photo's content.

"The date in the file is the date it was taken." It is the capturing device's clock reading, subject to drift, wrong settings, time-zone ambiguity and straightforward later editing. Treat it as a claim to be corroborated.

"The coordinates put them there." They put a device's positioning estimate there, at some moment, in the belief of that device. They do not identify the photographer, and being somewhere is not the same as the claim you are probably testing.

"Faking metadata takes real skill." Writing tag values is routine. The realistic barrier to a convincing fake is internal consistency across several files, not technical difficulty on one.

"An editing-software tag means the image was manipulated." It means the file passed through that software. Cropping, resizing and exporting produce the same trace as anything else, and many innocuous paths leave no trace at all.

"Metadata is where the answer will be." In most everyday disputes it is not. The contents of the frame, the timing and manner of the message, what the person says when asked a specific follow-up question, and information from outside the photograph entirely will usually settle things faster and more reliably than any field ever will.

"If it looks clean, it's safe to pass on." Different question, and worth separating from everything above. Whether a photo is trustworthy and whether it is safe to republish are unrelated; a file can be entirely genuine and still carry someone else's home address onward.

Related guides

See also:

• Which social platforms strip photo metadata automatically?
• Can metadata reveal if a photo was edited in Photoshop or Lightroom?