Google Photos Takeout Rescue Studio
Audit Google Photos Takeout media and JSON sidecars locally, match metadata conservatively, find exact duplicates, repair narrowly eligible JPEG dates, and build a reviewable rescue ZIP.
Takeout media, JSON sidecars, hashes, metadata repairs, and ZIP output stay in this browser. Nothing is uploaded to OpenFileTools.
1
Add an extracted Takeout batch
Choose the folder after you extract Google Takeout.
Large Takeout archives are safer to process by year or album. V1 audits extracted files rather than pretending a multi-gigabyte ZIP/TGZ can always be unpacked safely in browser memory.
Google Photos Takeout can be awkward to archive because downloaded media may sit beside secondary JSON files containing Google-specific dates, locations, descriptions, and other metadata. The safe response is not to overwrite every file. Takeout Rescue Studio audits the extracted batch, preserves existing embedded evidence, matches sidecars conservatively, reports exact duplicates, and creates a separate rescue copy only after review.
Audit an extracted Google Photos Takeout batch before changing metadata
- Extract the Takeout ZIP/TGZ with a trusted desktop extractor, then choose one year, album, or bounded folder batch in the browser.
- Run the audit to compare JPEG embedded capture dates with matched Google photoTakenTime evidence, unmatched JSON, ambiguous matches, and exact duplicates.
- Review the date policy, GPS privacy option, organization choice, and every conflict before building a rescue copy.
- Keep the audit CSV and untouched Takeout export until sample photos work correctly in the destination library.
How OpenFileTools processes it
Local processing, explicit choices.
OpenFileTools reads bounded JSON and JPEG metadata in browser memory, matches sidecars inside their original extracted folder, hashes same-size duplicate candidates with SHA-256, optionally inserts a minimal missing JPEG EXIF capture date without decoding or recompressing pixels, then builds a separate ZIP with rescued media, retained JSON evidence, audit CSVs, and a checksum manifest. No source file is overwritten or uploaded.
Quick technical summary
What this tool changes.
| Property | Behavior |
|---|---|
| Processing | Browser local; no Takeout media or JSON upload |
| Audit batch | Up to 15,000 files / 4 GB, with bounded JSON parsing |
| Direct repair | Missing JPEG EXIF capture date from unique photoTakenTime sidecar |
| Duplicate proof | Same byte length + SHA-256 |
| Package safety | Separate rescue ZIP; source files never overwritten or auto-deleted |
Audit before assuming Google Photos metadata is broken
Google's current Takeout guidance says original embedded photo/video metadata remains in downloaded files while additional Google Photos metadata can be exported to secondary JSON. The rescue workflow therefore compares evidence first instead of overwriting every file.
- Filesystem modified dates can change during download or extraction and are not treated as camera capture dates.
- A matching JSON sidecar is evidence, not automatic permission to overwrite existing EXIF.
- Ambiguous and unmatched sidecars stay visible in the audit.
Match sidecars conservatively and report duplicates exactly
Sidecars are matched only inside the same extracted folder using exact JSON title, direct sidecar filename, then constrained normalized-name evidence. Same-size files become duplicate candidates, but exact duplicates are confirmed only when SHA-256 also matches.
- Edited, resized, cropped, Live Photo companion, and similar-looking media are preserved.
- Duplicate reporting never deletes a source file in V1.
- Long filenames and newer .supplemental-metadata.json sidecars are handled without broad cross-folder guessing.
Keep automatic repair intentionally narrow
V1 can insert a minimal capture-date EXIF block into a JPEG only when the file has no EXIF block and a unique matching sidecar has photoTakenTime. The JPEG pixel stream is not decoded or recompressed. Other image/video containers remain byte-identical, with their sidecar evidence retained in reports.
- GPS restoration is off by default because location is sensitive.
- Google creationTime fallback is explicit because it can represent ingestion/upload rather than capture.
- Existing EXIF blocks are not overwritten automatically.
Questions, answered.
Why does Takeout include JSON files?
Google can place additional Google Photos metadata in secondary JSON files. Original embedded media metadata can still remain inside the photo or video.
Will the tool fix every HEIC, PNG, WebP, or video metadata field?
No. V1 audits those files and preserves them byte-for-byte. Automatic metadata insertion is deliberately limited to JPEGs with no EXIF block and strong sidecar evidence.
Can I use it on a 1 TB Takeout export at once?
No. Browser memory and hashing are deliberately bounded. Process large libraries by year, album, or folder batch and keep the original export as a backup.
Does it delete duplicate photos?
No. Exact duplicates are reported and preserved so you can decide what to remove later.
Related guide
Read the related guide