Why a Google Photos Takeout scrambles your timeline, and how the dates get back in

September 25, 2026 · 9 min read · by Nobody

If you have ever moved out of Google Photos with Google Takeout, you probably know the moment. You import the export into Apple Photos, Lightroom or a NAS, and a big part of your library lands on one day: the day you made the export. Screenshots from 2018, a WhatsApp picture from 2019, the edits you made in Google Photos, a lot of videos. All of it filed under last Tuesday.

Nothing is lost. Takeout does give you the dates. It just puts them somewhere your photo app never looks. I built Takeoutfix to put them back, and this post is what I learned about how Takeout stores metadata and why the timeline breaks.

What Takeout actually gives you

A Takeout of Google Photos is a set of zip files (often several, each up to 50 GB). Inside them is a folder per year, Photos from 2019 and so on, plus one folder per album. Next to almost every photo and video sits a JSON file. Here is one from the sample library on the site (a synthetic library I generated; no real photos):

{
  "title": "IMG_4410.jpg",
  "description": "Torre de Belém at closing time",
  "imageViews": "0",
  "creationTime": { "timestamp": "1555187469", "formatted": "Apr 13, 2019, 8:31:09 PM UTC" },
  "photoTakenTime": { "timestamp": "1555171512", "formatted": "Apr 13, 2019, 4:05:12 PM UTC" },
  "geoData": { "latitude": 38.6916, "longitude": -9.216, "altitude": 6, "latitudeSpan": 0, "longitudeSpan": 0 },
  "geoDataExif": { "latitude": 38.6916, "longitude": -9.216, "altitude": 6, "latitudeSpan": 0, "longitudeSpan": 0 },
  "photoLastModifiedTime": { "timestamp": "1555187469", "formatted": "Apr 13, 2019, 8:31:09 PM UTC" }
}

Three things in there matter.

photoTakenTime is when the photo was taken, as Unix seconds in a string. This is the date you want.
creationTime is when the file was uploaded to Google Photos. It looks like a date you could use, and it's often years off for anything you backed up late. I only fall back to it when there is no photoTakenTime, and the report says so for every file where that happened.
geoData holds the place, and 0, 0 means "no place", not a spot in the Gulf of Guinea. A caption you typed in Google Photos lives in description and nowhere else.

And then the part that causes the trouble: every file in the zip is stamped with the time the export was made. In the sample, that's 20 September 2026 for all 20 files.

Why the photo app picks export day

A photo app doesn't know Takeout exists. When it imports a file, it looks for a date inside the file (EXIF DateTimeOriginal in a JPEG or HEIC, the creation time in a video's header). If it finds one, the photo goes to the right day. If it doesn't, it falls back to the file's own modified date, which Takeout set to export day. The JSON next to the file is never opened.

Photos from a phone camera usually still carry their own date inside, so they survive. Screenshots, saved WhatsApp pictures, Google Photos edits and many videos don't, and those are the ones that pile up on export day.

Places and captions have the same problem. A place you added in Google Photos, or a caption you typed, exists only in the JSON. So even the photos that land on the right day can arrive without their place.

Here is the sample library on the site, before and after. Before, by the only date an importer can find for most of these files; after, by the capture date that Takeoutfix wrote back in:

The 20 photos and videos of the synthetic sample Takeout, counted by year. One scanned picture has no JSON and no date in its name, so it stays undated, and the report says so.

The names keep changing

The obvious fix is "for every photo, open the JSON with the same name plus .json and copy the date in". That used to be close to true. It isn't any more, and this is where tools written before 2024 fall over.

Classic: IMG_1234.jpg and IMG_1234.jpg.json.
Since 2024: IMG_1234.jpg.supplemental-metadata.json. A tool that looks for IMG_1234.jpg.json finds nothing and leaves the photo undated.
Cut short: JSON names are kept to 51 characters, .json included (this is the limit people report in the issue threads of Takeout tools). With the longer suffix, far more names hit it, and the cut lands anywhere: .supplemental-metada.json, .suppl.json, .s.json, or just ..json. For a long file name the cut lands inside the name itself.
Duplicates: when two photos share a name, the second is IMG_1234(1).jpg, and its JSON is IMG_1234.jpg(1).json, with the counter moved after the extension.
Edits: IMG_1234-edited.jpg has no JSON of its own (in a German export it's -bearbeitet, in a French one -modifié). It has to borrow the original's.

Each bar is the length the full name would need (the photo's name plus .supplemental-metadata.json); the lighter part is what gets cut. Below each bar is the name Takeout writes. Names from the synthetic sample.

So the matcher is a series of passes over each folder, from strict to loose: the name itself (with every supplemental-metadata variant and the (1) rule), then the title inside the JSON (which keeps the full, uncut name), then cut names by prefix, then edited copies, then Live Photo videos (IMG_3001.MP4 takes the date of IMG_3001.JPG), and last, album copies that borrow the JSON of the same photo in its year folder. Each pass uses maps keyed by name, so a folder of thousands of files is matched in one go rather than by comparing every file with every JSON. It never pairs a file with a JSON from another folder, except for album copies. When nothing matches, the scan says so and shows the names.

Takeout also splits big libraries over several zips, and a photo and its JSON can land in different parts. So every part is indexed before anything is matched.

Writing the dates back in

Once a file has its JSON, the date has to go inside it, in the place each format keeps it.

JPEG: EXIF DateTimeOriginal, plus OffsetTimeOriginal, GPS and the caption. I don't re-encode the picture. The EXIF block is replaced and every other byte of the file is copied as it was.
HEIC, PNG, WebP and a few others: these are written by ExifTool, Phil Harvey's Perl program, compiled to WebAssembly so it runs in the browser tab. On a 4.4 MB synthetic HEIC it took about 0.4 seconds per file in Chrome on a Mac, much of it ExifTool starting up again for each file.
MP4 and MOV: a video stores its creation time in three header boxes (mvhd, tkhd, mdhd) as seconds since 1 January 1904, in UTC. Those are fixed-size fields, so the date can be patched while the video streams through, without ever holding a large video in memory and without changing any box size (which would break the offsets that point into the video data). Place and caption go in through ExifTool for videos up to 64 MB.
Camera RAW: never rewritten. It gets an .xmp file next to it, which Lightroom and darktable read.

One detail I had to decide: EXIF's DateTimeOriginal has no time zone. It's a local time, "2019:04:13 17:05:12", and the JSON gives an instant in UTC. So I write the local time in a time zone you pick (your computer's by default) and add OffsetTimeOriginal, so apps that read the offset place the photo exactly. For photos taken while travelling, the local time will be in your home zone. The report says that too.

What a browser can't do

A web page can write files into a folder you choose (in Chrome and Edge on a computer), but it can't set their modified dates. Every fixed file gets today's date as its file date. That's why everything above is about dates inside the files: that is what Apple Photos, Lightroom and the NAS photo apps sort by. And a Live Photo comes out as a dated photo and a dated short video, not one merged Live Photo.

Nothing is uploaded at any point. The page reads the zips where they are, writes the fixed copy to your disk, and the server only ever sees a hash of the file list and two counts, to know whether you paid.

If you have a Takeout sitting in your Downloads folder, try Takeoutfix. The scan, the match report and 20 fixed files are free, so you can import those and check before paying. The whole library is $9, once, and re-running the same library with other options is free for 7 days.