Free · Private · No upload
Put the dates and locations back in your Google Photos export
Google Takeout moves every photo's date, location and caption into separate JSON files. Takeout Mender puts them back, lets you preview the changes first, and saves a repaired copy. Your photos stay on your device.
- Photos never leave your device
- Originals are never changed
- No account, no tracking
- Select source
- Choose output
- Analyze
- Restore
1 Add your Takeout
Add all the ZIP files, or unzipped Google Photos folders. You can also drop them anywhere on this card.
How do I get my Google Photos Takeout?
- Open takeout.google.com and click Deselect all.
- Tick only Google Photos and click Next step.
- Choose Export once, .zip, and the largest file size (fewer parts).
- When the email arrives, download every ZIP part.
2 Choose where to save
Pick a new, empty folder with room for about the size of your Takeout. Your originals are never changed.
3 Analyze your files
A quick scan shows how many photos match their metadata before anything is written.
Preview: what will change
Browse and preview files
Click a file to preview it and see its matched date and location.
4 Restore
Advanced options
Google stores the exact moment in UTC. Photo apps expect local time, so pick the zone where most photos were taken.
All done
The repair report lists your file names, so do not post it publicly. Copy diagnostics contains no file names or GPS data. What each one contains.
IMG_4821.jpg
Date taken: unknown
Location: none
IMG_4821.jpg
Date taken: 11 Apr 2019, 16:26
Location: 48.8500, 2.3500
What it fixes
JPEG photos: date taken, GPS and description are written into the file. MP4 / MOV videos: the creation date inside the file is corrected. PNG photos get the same. WebP gets EXIF too. Other formats (HEIC, GIF): the file is copied unchanged and an XMP sidecar with the correct date and location is written next to it, which Immich, digiKam, Lightroom and PhotoPrism read (Apple Photos does not). Photos that already contain a date keep it. Files with no matching JSON are copied unchanged and listed in report.txt. "Copied" never means "fixed".
Why are some photos unmatched?
Takeout shortens long filenames, adds (1) to duplicates and sometimes omits the JSON. Take a look at the list in report.txt. Edited copies reuse the original's JSON automatically.
Do file "modified" dates change?
No. Browsers can't set them, so copies show today's date in your file manager. Photo apps read the dates embedded inside the files, which are now correct.
Is it safe?
Your Takeout folders are only read. Everything is written to the output folder you choose.
Privacy you can verify
Your photos are processed on your own computer. Nothing is uploaded, and there is no account or tracking. To check, watch your browser's network monitor while you scan and fix: you will see no uploads. The page loads no third-party code (the metadata library is bundled inside it), so it also works offline once opened. It also ships with a Content-Security-Policy, that tells your browser to block all outgoing connections. The line below reads the policy declared by this page. It is a declaration, not a test of your browser and not proof about any other copy of the page:
My Takeout photos show the wrong date, or 1970
Takeout stores the real "date taken" in a separate JSON file instead of the photo. Apps that read only the photo fall back to the download date or 1970. Takeout Mender copies the real date back into each photo.
Does it work in Safari or Firefox?
Yes, in compatibility mode. It reads your ZIP files or a folder and gives you the fixed files as ZIP parts. Chrome and Edge can write straight to a folder, which is faster for big libraries.
Does it work with non-English Takeouts?
Yes. It recognizes common translated "edited" suffixes and year-folder names. If something is missed, report.txt lists what was copied unchanged.
How big a library can it handle?
In Chrome or Edge, libraries of any size, since files are streamed one at a time. In compatibility mode, keep to a few GB at a time.
Something went wrong. What should I try?
"Chrome blocked that folder": pick a subfolder you created, not Downloads, Desktop or a drive's top level.
Many files unmatched: add every ZIP part of the same export. The metadata files are often in a different part than the photos.
Drive full or unplugged: the run pauses by itself. Fix it, then press Resume. Files already written are never lost.
A ZIP won't open: download that part from Google again, since large downloads sometimes truncate.
Still stuck: click Copy diagnostics and share the text when you ask for help. It contains no photo names.
How privacy works
Everything runs in your browser. You grant access to specific folders or ZIP files through the browser's own picker, and the page can read only what you choose and write only to the output folder you choose. Once loaded, it makes no network requests of its own: the metadata library is bundled in the page and the page declares a policy blocking outgoing connections. A browser cannot prove that to you, so verify it: watch your browser's network monitor while you scan and fix. Hosting providers can still see that someone loaded the page, as with any website.
Technical details
Matching: each photo is paired with its Google JSON sidecar by filename with deterministic priority: exact name, edited-copy variants, duplicate suffixes like (1), Google's 46-character truncation, Unicode NFC/NFD normalization, then a last-resort similar-name match flagged as "needs attention". Matches carry confidence levels (exact / truncated / ambiguous / fuzzy). A match means a sidecar was found, not that the result is correct. Conflicting sidecars are rejected rather than applied silently.
Writing: JPEG and PNG get EXIF (date taken, GPS, description). MP4 and MOV get their container creation time. Other formats get a sidecar file. Existing dates are kept unless you turn that off. JPEGs are re-read after writing to check the date.
Duplicates: files of equal size are hashed, then compared byte for byte before one is skipped. Nothing is deleted from your Takeout.
Format support: what is and isn't verified
| JPEG | EXIF date, GPS, caption. Re-read by this tool after writing. Behavior in your photo app is not verified by the developer. |
| PNG | EXIF chunk. Many apps ignore PNG EXIF; support varies. Unverified in real apps. |
| MP4, MOV | Container creation time. Not every app uses it and time zone meaning varies. Unverified on real files. |
| WebP | EXIF chunk written into the file. Verified with an independent image library on synthetic files; app support varies. |
| HEIC, GIF, AVI, others | File copied unchanged plus an XMP sidecar. Immich, digiKam, Lightroom and PhotoPrism document sidecar support; Apple Photos does not read them. Unverified here. |
Tested so far: logic with synthetic files in a simulated browser. Not tested: real Takeout exports, real Chrome, Edge, Firefox and Safari, or import into other apps.
Known limits (what this tool cannot do)
- It cannot write dates inside HEIC (and some other) files. It writes an XMP sidecar instead, which some apps read and Apple Photos does not. WebP gets an EXIF chunk when the browser can process the file.
- It cannot tell you your photos will import correctly into a specific app. Check a sample first with "Try on 20 photos first".
- In Firefox and Safari, results download as ZIP parts, so keep to a few GB at a time, and a single file over 1.5 GB inside a ZIP cannot be handled there. Chrome and Edge stream such files straight to your folder.
- A sidecar match means a JSON file was found, not that its date is right. Similar-name matches are flagged so you can check them, and you can choose the right JSON yourself or ignore a match.
- Resume requires a valid
.tm-donev3 marker bound to source path, size, source fingerprint, output name, output size, output fingerprint, mode and date. On resume the tool re-fingerprints the existing output and refuses to skip if it changed. Source and output fingerprints are full-file SHA-256 digests computed in 1 MiB streaming chunks (bounded memory). Unproven existing files are preserved; restored output uses a conflict filename. - GPS coordinates of exactly 0° are treated as valid. Invalid or out-of-range coordinates are dropped. Google Takeout sometimes stores missing location as 0,0; those values will be written unless you enable “Don't write GPS”.
- “Independently verified” means the tool re-read the expected date from the written file. It does not by itself mean GPS and caption were proven unless the full-metadata counter also increased.
- Photos whose original date exists nowhere (no JSON, no embedded date, no date in the filename) can only be given a date by you.
- It has been tested with synthetic files, not yet with a wide range of real exports.
Not affiliated with Google. Google Photos and Google Takeout are trademarks of Google LLC. Provided as is: keep your original Takeout and your Google Photos library until you have checked the results. Version 1.2.3.