Fix Google Takeout Photo Dates on Windows

Why Google Takeout dates look wrong

Takeout does not lose your capture dates — it moves them. The photo files arrive on your PC carrying the timestamp of the download, because that is genuinely when those files were created on your disk. The date the photograph was actually taken is written into a small companion .json file that Takeout ships beside each image.

Windows has no idea those two files are related. It sorts by the timestamp it can see, so a twenty-year library collapses into the afternoon you downloaded it. Nothing is damaged; the evidence is simply sitting in a file Explorer will not read.

Takeout is the only export whose own metadata records PDR parses. There is no Apple, Facebook, Flickr or Amazon Photos equivalent, and for those exports the date has to come from inside the image files instead. If you are exporting from iCloud, OneDrive or Dropbox, the cloud export guide is the page to follow.

Keep every ZIP and JSON record together

Add the ZIP files to PDR exactly as Google produced them. It reads .zip and .rar archives directly, so there is nothing to extract, and extracting is where most Takeout repairs go wrong — hand-merging the parts is how a photo and its record get separated in the first place.

Two other habits cost people their dates before PDR ever sees the files. Do not convert HEIC to JPEG first — PDR reads HEIC and MOV as they are, and the conversion is a common way to drop the capture time. And do not download only some of the parts: a missing part is missing photos.

How PDR matches records across archive parts

Google splits a large Takeout into numbered parts, and it splits them by size rather than by keeping things together. A photo routinely ends up in part seven while its .json record is in part eight. Before the repair run starts, PDR scans every part you added and builds an index of the records it found, so a photo can be matched to a record from a different archive part.

Matching a record to a photo is harder than it sounds, because Google decorates the record’s filename in several ways. PDR handles each of these:

The third row is the one that bites. Where you have several copies of the same photo, Google exports them as MOVIE.m4v, MOVIE(1).m4v and so on, but writes that copy number at the end of the record’s name rather than in the middle. Read loosely, every one of those records looks like it belongs to the first video — which is how a video shot in March gets handed a date from February. PDR reads the number as the copy index it is. Where a name has been truncated it does not guess at all: it opens the record and checks the title inside.

What PDR changes — and what it leaves untouched

PDR never edits your download. Every repair produces a fresh copy in a new output folder, and the Takeout ZIPs are only ever read. If you dislike the result you delete the output folder and nothing has been lost.

Into each corrected copy PDR writes the capture date it worked out, and it can write that date back into the file’s EXIF. Duplicates are skipped as it writes, using a SHA-256 hash of the file’s contents — so a photo that appears in two parts is written once, but two different photos that merely look alike are both kept.

Some things in a Takeout do not survive the trip, and it is fairer to say so here than to let you find out later. The details of what carries over and what does not are in what comes across and what does not.

How to verify the corrected copies

Do not take the result on trust — the point of the confidence scoring is that you can check it. Every corrected copy is renamed from the date PDR settled on, with a suffix recording how sure it is:

• _CF — confirmed. The date came from the Takeout record, EXIF or an embedded XMP block.
• _RC — recovered. The date was read out of the filename, or from a file timestamp that looked genuinely older than the file.
• _MK — marked. PDR could not settle it confidently and is telling you so.

PDR also records, per photo, which source answered — including naming the archive part when a record came from a different one. Spot-check a handful against what you remember, and sort by the marked ones first: those are the photos worth your attention, and there are usually far fewer of them than you fear.

When PDR cannot recover the date

Sometimes the date is genuinely not there. A photo whose record was never downloaded, or which was uploaded to Google without a capture date in the first place, has nothing to recover. When every source is silent PDR falls back to the file’s own timestamp and labels it as the fallback it is, rather than presenting the download date as the day you took the picture.

It is worth knowing the limits precisely:

• A separate .xmp file is never read for a date. PDR opens those only for face regions.
• A date can only be read from a filename when the name contains a full year, month and day.
• The record has to come from a Takeout. Other services’ exports have no equivalent PDR can parse.

The general guide to wrong photo dates covers what to do with the photos that come back marked.

Desktop app or 200 MB web demo?

For a real Takeout, the answer is the desktop app, and it is not a close call. The web demo accepts one ZIP file of up to 200 MB, photos only — that is a few hundred photos, and a Takeout is usually many gigabytes across many parts. The demo also cannot do the thing this page is about: matching a record across archive parts needs all the parts, and it only takes one.

What the demo is genuinely good for is seeing the confidence scoring behave on your own files before you install anything. Make a small ZIP from a few dozen photos and their records, run it, and see how much comes back confirmed.