What photo timestamps reveal when GPS is already gone

Most location-privacy advice, on this site and everywhere else, is organised around one field: the GPS block. Clear the coordinates and the map pin disappears. That advice is correct as far as it goes, and it leaves an entire category of disclosure standing, because time is a location signal too — just an indirect one that has to be reasoned about rather than read off.

This is a different problem from the one covered in what your filename and file dates reveal after you strip metadata. Those live outside the image and survive a wipe untouched. The clocks described here are inside the bytes, and a full wipe does clear them. The reason they still matter is that people keep them on purpose — a date feels harmless, feels useful, feels like the one field worth preserving — and partial removals leave them behind by accident.

The clocks inside one photograph

A single JPEG from a modern phone can hold four or five distinct time values, written by different parts of the device and meaning different things.

The capture time. DateTimeOriginal is the camera's own reading of when the shutter fired. It is a plain local-clock value with no zone attached — 2026:07:14 21:08:33 and nothing more. On its own it is ambiguous by up to a day's worth of offsets, and that ambiguity was the point of the next group.

The zone offsets. Three tags — OffsetTime, OffsetTimeOriginal and OffsetTimeDigitized — record the time zone belonging to the modify, original and digitised timestamps respectively. They were introduced in the Exif 2.31 revision of July 2016, precisely because before that the specification had no standard way to note a zone, so a local reading could not be resolved to an absolute moment. They hold a short string in the shape +01:00 or -07:00. When present, they state your offset outright.

The GPS clock. Inside the GPS block sit GPSTimeStamp and GPSDateStamp, and these matter more than their names suggest: they record the UTC time and date of the satellite fix, not local time. They are timestamps that happen to live in the location block, which is why they are so often collateral in a partial clean-up — either wiped along with the coordinates by a thorough tool, or left sitting there by one that only targeted latitude and longitude.

Sub-second precision. SubSecTimeOriginal holds fractional seconds for the capture time. Nobody's privacy turns on a fraction of a second in isolation, but it orders a burst exactly and makes two files easy to distinguish or match.

File-system dates. Created and modified, held by your operating system rather than the image. Different layer, different rules, covered on the filename page linked above.

How a time becomes a place

The inference is arithmetic, and it only needs two of the values above.

If a file carries a local capture time of 21:08 and a GPS timestamp reading 04:08 UTC, the difference is your offset: seventeen hours behind, or equivalently a zone somewhere in the Pacific. If it carries an OffsetTimeOriginal of +05:30, no arithmetic is needed at all — that offset is shared by a very short list of places. An offset is a band of longitudes rather than a pin, so this is regional inference, not a street address. It is still a large reduction from "somewhere on Earth".

Three things sharpen it considerably.

Daylight saving behaviour. Whether the offset shifts by an hour between summer and winter files, and roughly when it shifts, separates regions that otherwise share the same nominal offset. That takes a band and narrows it toward specific countries.

A set rather than a file. Across a run of photos, the offset that keeps recurring reads as home and the ones clustered into a fortnight read as a trip, complete with departure and return dates. This is the same aggregation effect described in the site's guide to why groups leak more than individuals; timestamps are a particularly clean example of it because they sort so neatly.

A camera clock that was never adjusted. Phones set their clocks from the network and follow you across zones. Standalone cameras usually do not — they keep whatever local time you set at home, so abroad they produce a local reading that disagrees with the satellite reading by your home offset rather than your current one. The mismatch is not noise. It is a second data point about where the owner normally lives.

Separately from place, the time of day is its own disclosure. A photo timestamped 02:14 says something a photo timestamped 14:00 does not, and a hundred photos clustered between 07:30 and 08:10 on weekdays describe a commute. If your concern is a specific person rather than a general audience, that pattern is often more useful to them than a coordinate would be, because they already know the city.

What this tool does with the clocks

Worth being exact, because vagueness here is not a kindness. MetadataWipe decodes your image and re-encodes it from the resulting pixels, which means the file you download is generated rather than edited. Header structures are not copied across, so the capture time, the offset tags, the sub-second field and the entire GPS block are simply not present in the export. The work happens in the page, in your browser.

Three consequences follow from how that is built. First, it is all-or-nothing: there is no switch to keep the date and drop the coordinates, because nothing from the original header is carried forward. Second, the tool handles JPEG and PNG only — other formats are rejected rather than silently passed through, so a HEIC or RAW original needs converting first. Third, the metadata check shown before and after cleaning is a heuristic marker scan, not a field-by-field dump: it looks for signs of an EXIF block, a GPS mention, or PNG text and timing chunks, and reports whether it found any. It will tell you that a file appears to carry EXIF and location markers. It will not print your offset value back to you. To read the actual numbers before deciding, open the file in a dedicated metadata viewer — the values are worth seeing once, because they are more specific than most people expect.

For PNG files, note that the format keeps its own timestamp chunk, tIME, separate from anything EXIF-shaped. The check flags PNG timing and text chunks when it sees them, and re-encoding produces a file without them.

A workflow that treats time as location data

1. Read the clocks before you clear them. Look at the capture time, any offset tag, and the GPS timestamp in the file you are about to send. You are deciding what to remove, which means knowing what is there.
2. Check zone fields specifically, not just the map pin. A file can show no coordinates and still show +05:30. Searching for the word "location" in a properties panel will not surface that.
3. Remove the whole block rather than editing one field. Selective deletion is where the GPS timestamp survives a location wipe. Rebuilding the image removes the category instead of playing whack-a-mole with tags.
4. If a date must travel, say it in words. Write "taken on the 14th" in the email. A stated date discloses the one fact you intended and none of the surrounding structure.
5. Be consistent across the whole set. Cleaning nine of ten photos leaves the tenth to anchor everything the other nine implied. Offsets are exactly the kind of signal that only needs one survivor.
6. Check what surrounds the file. Archives store per-entry modification times, sidecar files can hold a copy of the header, and captions frequently restate a date the file no longer contains.
7. Finish with the outside layer. Many camera apps write the capture date straight into the filename, so the date you just stripped can still be sitting in plain text on the attachment.

Common mistakes and misconceptions

"Location services were off, so there's nothing locational in the file." No coordinates, true. The clocks are written by the camera app regardless of location permissions, and the reasoning above needs no satellite fix at all when an offset tag is present.

"I removed GPS, so the GPS time went with it." Sometimes. It depends entirely on whether the tool cleared the block or the two coordinate tags. Verify the output instead of assuming.

"It's only a date — everybody can see when I posted." A posting time is when you uploaded. A capture timestamp is when you were physically at the scene, and the gap between the two is itself informative. They are not the same disclosure.

"My camera's clock is wrong, so the timestamps are useless to anyone." A clock that is consistently wrong by a fixed amount is a fingerprint that links your files to each other, and its disagreement with satellite time can indicate your home zone. Wrong is not the same as uninformative.

"Screenshots have no capture time." They have no camera capture time. Depending on the tool and the format they may carry other timing information, and they always carry file-system dates and often a date in the generated filename. Check rather than assume, since screenshot tooling varies widely.

"The platform strips this anyway." Some services do re-encode uploads and discard headers; others preserve the original for download, and the same company's web uploader, mobile app and direct-message path can behave differently. If it matters, clean before sending and the question stops being relevant.

Related guides

See also:

• What metadata does your phone camera record?
• What your filename and file dates reveal after you strip metadata