Why do my Google Photos have the wrong date?
You downloaded years of photographs from Google Takeout, and every one of them says it was taken on the day you downloaded it. Ten years of pictures land in your photo app as a single enormous day.
Can you get it back?
Almost certainly. Counted across one real Takeout of more than two thousand photographs: about half still carry their capture date inside the file, and for the other half it sits in a small JSON file beside the picture. Fewer than one in a hundred had no date anywhere at all. So it is nearly always already in the folder you downloaded - but for around half the library that JSON file is the only copy that exists, which makes deleting them the one mistake here you cannot undo.
What actually happened
Two different things go wrong here and they get run together. The first happens to everybody: the file that lands on your disk carries a modification time of the moment Google packed it, and most photo software sorts by exactly that. So the pictures arrive as one enormous day stamped with the date you pressed download, whatever else is true about them.
The second is the one worth measuring. Takeout is widely said to strip the capture date out of every photograph. Counted across more than two thousand pictures in a real export, about half still carried it and about half did not. For that half, the JSON file beside the picture holds the only copy of the date that exists anywhere, and once it is gone no tool can work the date out again.
Because the split is roughly even, two people can look at the same kind of export and come away certain of opposite things. Whoever checks a photograph from the half that kept its date concludes Takeout is fine and the problem is their photo app. Whoever checks one from the other half concludes Takeout strips everything. Both are half right, which is why the advice online contradicts itself. The practical consequence is that a tool assuming the date is always in the file writes nothing for half your library and reports success. Where a photograph carried a date in both places the two agreed every single time, across more than a thousand of them, so the sidecar can be trusted for the half that need it.
How to fix it
You do not need us for this. Two routes, both free.
- exiftool, if you are comfortable in a terminal
- Check what your sidecars are actually called before you run anything. In the export measured here every single sidecar was named IMG_1234.jpg.supplemental-metadata.json, and the widely copied one-liner that ends .json matches none of those - it runs, reports no errors, and writes nothing. Matching the name that is really there: exiftool -r -d %s -tagsfromfile "%d%f.%e.supplemental-metadata.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -overwrite_original -ext jpg . Google is also reported to cut that long suffix off partway when the whole file name runs long, giving names like .supplemental-me.json. A fixed pattern skips every one of those too, and exiftool will not tell you how many it skipped.
- Google Photos Takeout Helper, if you would rather not
- An open-source command line tool built for this exact job, and it handles the naming variants. If all you want is your Google photographs dated correctly and written into folders, it does that well and it is the right answer for a one-off.
How Muletto does it
Muletto matches sidecars by prefix rather than by a fixed ending, so a truncated name is found as readily as the full one, and it reads the date out of the photograph itself where that is still there. It reports how many pictures it could not find a date for anywhere, rather than moving on quietly. The date and, where Google kept it, the location are written into the file, so whatever you import into afterwards reads them without needing the JSON any more. It runs in the browser and the archive is never uploaded.
Stopping it happening again
Keep the JSON files until the dates are written into the pictures. They look like clutter and for about half your library they are the only copy of the capture date. Once the dates are in the photographs themselves, the sidecars can go.
Measured against one real Takeout of more than two thousand photographs. Roughly half carried an embedded capture date and roughly half did not; for about half the library the sidecar held the only copy, and fewer than one per cent had no date in either place. Every sidecar used the same .supplemental-metadata.json ending, and about one media file in nine had no sidecar at all. Where both existed the two dates agreed in every case, of more than a thousand. That is one export rather than a survey, so the proportions are an indication rather than a rule - what they do settle is that the flat claim Takeout strips the date from everything is not right.