Why two metadata checkers disagree about the same photo

This is not a question about whether removal worked, and it is not the familiar problem of two copies of a picture having travelled through different channels. It is narrower and more unsettling than either: one file, sitting on your disk, unchanged between tests — and two readers that tell you different things about it. Your file properties pane says there is nothing there. A browser checker flags possible GPS. A command-line tool prints forty fields. Nothing in the file moved between those three answers, so at least two of them are incomplete, and the useful skill is knowing which. The disagreement is almost never a bug. It is the predictable result of readers that look in different places, to different depths, with different methods, and then compress what they found into a one-word verdict.

Want a local check before you share? MetadataWipe scans and rebuilds one JPEG or PNG at a time inside this page — no account, no upload required, and the file never leaves your device.

Open MetadataWipe tool

What a checker is actually reporting

A metadata reader does three separate things and shows you the result of only the last one. It decides which parts of the file to look at. It decides how to interpret the bytes it finds there. Then it decides how to summarise that for you. Two tools can perform step two flawlessly and still disagree, because they made different decisions at step one — and the summary at step three hides the difference. "No metadata found" is shorthand for "none of the things I look for turned up in the places I looked", and no interface has room to print the footnote.

This is why the instinct to treat a disagreement as a reliability contest leads people wrong. The question is not which tool is better. It is what each tool's scope was, because once you know that, the two answers usually stop contradicting each other and start fitting together.

The seven reasons two readers disagree

They read different containers. This is the big one, and it accounts for most disagreements on its own. "Metadata" is not one structure. A JPEG can carry an EXIF block in an APP1 segment, an XMP packet in its own APP1 segment identified by an Adobe namespace, an IPTC block commonly carried in an APP13 segment, an embedded colour profile typically in APP2, a manufacturer's MakerNotes nested inside the EXIF, and plain comment segments besides. A PNG does not use any of that; it carries named chunks, including the textual tEXt, iTXt and zTXt types, a timestamp in tIME, an embedded profile in iCCP, and optionally EXIF in eXIf. A reader built to show EXIF is silent about XMP, which means a file that has had its EXIF stripped by one tool and still holds a full XMP description will read as clean in one panel and populated in another. Both readings are correct about what they cover.
They read different amounts of the file. Metadata usually lives near the front of an image, so fast readers sample the beginning rather than the whole file. That is a sensible trade and it is also a scope limit. This site's tool is explicit about it in its own code: the check reads the first 512 KB and examines roughly the first 256 KB of that. A desktop parser that walks the entire file to the end has a strictly larger field of view, so when the two disagree in that direction the deeper read is the one carrying new information.
One is parsing and the other is pattern-matching. A parser follows the format's structure: it finds a segment, reads its length, identifies the tag, decodes the value, and can tell you that GPSLatitude holds a specific number. A heuristic scanner looks for recognisable byte patterns and reports that something that looks like metadata is present. Heuristics produce both error types. They raise false positives, because a literal string such as GPS can appear in a profile name, a caption or an application tag with no coordinate anywhere in the file. They also produce blind spots, because a check that identifies EXIF by looking for an APP1 segment with the Exif identifier will not name an IPTC block sitting in APP13 — even though the block is right there. Tools that work this way tend to hedge their wording with "possible", and that word is doing real work.
One is showing the file and the other is showing its own records. Photo libraries, operating system shells and platforms all maintain indexes, previews and thumbnail caches, and those are updated on their own schedule. A gallery app can display a location for an image whose coordinates it recorded when the photo was imported, long after the coordinates were removed from the file — because the app is reading its database, not re-reading your bytes. A shell preview can show a stale thumbnail for the same reason. Published pages behave the same way: a site may hold its own copy of location data from your account or your post, which is why an image can look clean in every local reader and still appear on a map. That is platform data, not metadata resurrecting itself, and removing it is a separate job done in a different place.
Filesystem attributes are sitting next to the photo's own tags. A properties pane mixes two sources in one list without labelling the boundary. Date taken comes from inside the image. Date created and date modified come from the volume, change when the file is copied or downloaded, and are completely untouched by metadata removal. Sidecars belong to the same category of near-miss: an edit description stored beside the image, or an adjustment file written next to an original on an Apple device, is a separate file that some readers merge into their display and others ignore entirely. When two tools disagree about a date, check first whether they are even reading the same object.
The embedded preview is a file inside the file. Cameras commonly store a small thumbnail within the metadata block, and that thumbnail is itself an image that can carry its own tags. A reader that descends into it reports more than one that does not, and a tool that rewrote the main header without regenerating the preview can leave a genuine mismatch behind — a clean outer header and a stale inner one. Rebuilding the image from decoded pixels avoids that whole class of problem, because the output has no embedded preview at all.
You checked two different objects and did not notice. Mundane and extremely common. The thumbnail in a mail composer is not the attachment. The rendered version of an edited photo is not the original the library is still storing. The copy in your downloads folder is not the copy you dragged into a form ten minutes earlier. Before you investigate a disagreement between readers, confirm there is only one file involved — which is the two copies of the same photo problem rather than this one, and it has a different fix.

How to resolve a disagreement in five steps

Pin the object. Copy the exact file you care about to a known folder and run every test on that path. No thumbnails, no previews, no "the one I just sent".
Get one reader to name fields. You need at least one tool that prints labelled values rather than a verdict. A populated field settles the question instantly; a verdict never can, because you cannot see its scope.
Separate found-something from found-location. If a scanner flagged GPS, look for an actual latitude and longitude in the parsed output. No coordinate pair means the flag was a text match on a profile name or a caption.
Check the containers the quiet reader skips. Specifically XMP, IPTC and the colour profile for a JPEG, and the text chunks for a PNG. This is where "stripped" files most often still hold a description, a byline or a copyright line.
Re-check the export, never the input. After cleaning, point your readers at the new file. Confirming that the original still has GPS tells you nothing about the copy you are about to send, and it is a surprisingly easy mistake to make when two files have similar names. The procedure for this is covered in how to verify metadata was removed.

Which reader wins

There is a clean rule, and it is not "trust the most expensive tool". Presence beats absence. If any reader shows you a populated field, that field is in the file and no number of empty panels overrides it. If a reader shows you nothing, you have learned that nothing turned up inside that reader's scope — which is genuinely useful and is not a proof. So a single positive outranks a pile of negatives, several independent empty results are a reasonable basis for sending an ordinary photo, and when the stakes are high you want one deep field-level read rather than three shallow verdicts that happen to agree.

What this site's checker claims, stated precisely

Since this page is about scope, here is the scope of the check on this site, read from the tool's own code rather than its marketing. MetadataWipe accepts image/jpeg and image/png only, one file at a time, and rejects anything else outright. Its check reads the first 512 KB of the selected file and examines roughly the first 256 KB. For a JPEG it looks for an APP1 segment carrying the Exif identifier and for the literal text GPS, and reports those as "possible" findings. For a PNG it walks the chunk list looking for eXIf, tIME, tEXt, iTXt, zTXt and iCCP. It then decodes the image, draws it to a canvas at the original pixel dimensions, exports a new file from that canvas — a fresh encode at a fixed JPEG quality of 0.92, or a PNG — names the result by appending -metadatawipe before the extension, and runs the same check again on the export so you can see the before and after. Your selected file is never modified, and all of it happens inside the page on your own device.

Two honest consequences follow. Because the output is generated from decoded pixels rather than edited in place, every metadata segment in the source is absent from the export whether or not the check knew how to name it — which is why the rebuild is stronger than the scanner that describes it. And because the check is a heuristic over the front of the file, a "no obvious metadata detected" result is a sanity check and not a field-by-field clearance. For an everyday share that is the right amount of rigour. For a formal process, open the export in a full reader and look at the fields.

Common mistakes and misconceptions

"The tools disagree, so one of them is broken." Usually neither is. They have different scopes and the interface does not show you the scope. Work out what each one covers and the contradiction normally dissolves.

"The strictest tool is the most accurate." A tool that flags more is not necessarily seeing more — a loose text match flags more than a careful parser while knowing less. More alerts is not more insight.

"My properties pane says clean, so it is clean." Properties panes typically display a small set of EXIF fields they are built to show. XMP, IPTC and text chunks can be full while that pane is empty.

"The gallery still shows the location, so the strip failed." Check whether the app is reading your file or its own index. If removing the file's coordinates did not change the app's display, you are looking at a database entry, and that is a separate thing to clear.

"It found GPS, so my coordinates are in there." Not until you have seen a latitude and a longitude. "Possible GPS" from a byte scanner can be a colour profile name. Escalate to a parser before you panic.

"Both checkers said clean, so this file is anonymous." Empty headers are not anonymity. The picture content, the encoder's characteristics, the filename and the filesystem dates all sit outside the metadata question and all survive it.

"I will just use whichever tool gives the answer I want." Worth naming because it is the real failure mode. Running readers until one says clean is not verification; it is selecting for the shallowest scope you can find.

Related guides

Frequently asked questions

Two tools disagree about my photo. Which one should I believe?

Believe the one that names fields over the one that gives you a verdict. A reader that prints GPSLatitude, DateTimeOriginal and Model as labelled values is telling you what it found and where; a reader that says clean or not clean is telling you the outcome of a test whose scope you cannot see. That asymmetry matters because presence and absence are not equally strong evidence. If any reader shows you a populated field, that field is in the file and the argument is over. If a reader shows you nothing, all you have learned is that nothing turned up within whatever that particular reader looks at, which may be one container, a limited number of bytes, or a cached record rather than the file in front of you. So a single positive outranks any number of negatives, and when every reader you have comes back empty you have a reasonable result rather than a proof.

My computer says there is no date taken, but an online checker found metadata. What is going on?

Almost always one of two things, and they are easy to tell apart. The first is containers: an operating system properties pane typically surfaces a short list of EXIF fields it knows how to display, so a file whose capture time was stripped but which still carries an XMP packet, an IPTC block, a colour profile or a software history can read as blank there and as populated in a reader that walks every segment. The second is that the properties pane is showing you filesystem information alongside the photo's own tags. Date created and date modified come from the volume, not from inside the image, and they change when a file is copied, downloaded or re-saved. People read those rows as if they were part of the picture. They are not, they survive metadata removal untouched, and they are worth checking separately because they leak a timeline of their own.

Does a clean result from MetadataWipe's own check mean the file is definitely clean?

It means the tool's built-in check found no markers it looks for, which is a sanity check rather than a forensic clearance, and the page says so deliberately. Read from the tool's own code, the check reads the first 512 KB of the file and examines roughly the first 256 KB of that. For a JPEG it looks for an APP1 segment carrying the Exif identifier and for the literal text GPS. For a PNG it walks chunk types looking for eXIf, tIME, tEXt, iTXt, zTXt and iCCP. That is a useful, fast, local confirmation that the obvious layer is gone, and it is not a field-by-field parse of every container in the file. For an everyday share it is enough. For a claim, a contest entry, a dispute or anything where you may be asked about the file later, open the export in a full metadata reader and look at the actual fields before you send it.

Why would a checker flag GPS on a photo that never had location switched on?

Because some checkers pattern-match rather than parse, and the three letters GPS appear in more places than a coordinate block. A tool that scans raw bytes for that string can trip on a colour profile name, an XMP property, a caption, an application tag, or any other text that happens to contain it, and it will usually phrase the result cautiously for exactly that reason. The resolution is to stop asking whether something was found and start asking what. Open the same file in a reader that prints labelled fields and look for a populated latitude and longitude. If there is no coordinate pair, the flag was a text match and there is no location in the file. If there is one, you have your answer and you can clean the file and re-check the export.

Done diagnosing and ready to clean? Rebuild the file here — scanned and re-encoded in your browser, with nothing sent anywhere.

Try MetadataWipe free