Confirm GPS metadata was removed from an image

Removing location metadata is easy to claim and important to verify. This capability compares parsed image metadata captured before and after a strip operation, identifies GPS-related fields recursively, and confirms that none survive in the result. It reports the exact metadata paths removed, making the result useful for automated privacy checks, publishing workflows, and audit records. The comparison is deterministic, runs without network access, and accepts common nested EXIF and XMP metadata structures.

Capture comparable metadata before and after stripping

Start by extracting metadata from the original image and from the stripped output with the same metadata reader whenever possible. Using one reader keeps namespace names and nesting consistent, which makes the removed-tag report easier to interpret. The checker walks both objects recursively, so a camera field such as <code>EXIF.GPSLatitude</code>, an XMP key such as <code>XMP.exif:GPSLongitude</code>, and values inside a nested <code>GPS</code> object can all be recognized.

The input is metadata, not image bytes: this capability verifies the evidence produced by your extraction and stripping workflow rather than editing the file itself. Preserve the original metadata snapshot before running the stripper, because it establishes which location tags existed and lets the result name what disappeared. Other camera, copyright, orientation, and descriptive fields may remain without causing an error.

For reliable audits, keep the two snapshots with the strip job identifier and ensure they refer to the exact source and output files being evaluated.

Understand confirmation and removed-tag reporting

A successful response means the after snapshot contains no recognized GPS leaf tags. A before snapshot with no GPS tags is still a valid comparison: it confirms that the after snapshot is also clear and returns an empty removed list. Recognition is based on metadata key names and GPS namespaces rather than coordinate values, so a present GPS tag still counts when its value is zero, blank, or null.

That conservative rule matters because privacy verification should test whether the field remains, not guess whether its value is usable. Empty GPS container objects do not count as tags because they carry no leaf metadata. Paths are stable and sorted, allowing callers to store results, compare runs, or assert an exact removal policy without depending on object insertion order.

Fail the workflow when location metadata survives

Treat that result as a failed strip operation: do not publish, upload, email, or archive the image as privacy-safe. Instead, inspect whether the stripping tool omitted an EXIF GPS field, preserved an XMP location property, or rewrote metadata under a different namespace. Run the strip step again with the appropriate policy, extract fresh metadata from the new output, and repeat the confirmation.

This fail-closed behavior prevents a partial cleanup from looking successful merely because some coordinates disappeared. The traversal is bounded by depth and node limits so malformed or unexpectedly huge metadata cannot consume unbounded resources. It is also deterministic and uses no network, current time, or random values, making the same pair of snapshots produce the same answer.

Use the response as one control in a larger privacy pipeline; also ensure that filenames, visible pixels, captions, sidecar files, and platform-specific asset databases do not independently disclose a location.