First: Google says original embedded metadata is preserved
Google's current Photos Help documentation says a downloaded photo or video's embedded metadata still preserves the original timestamp, even though the operating system can assign a new filesystem timestamp when the file is downloaded. It also says additional metadata that is not from the original file, such as Google Photos comments, can be downloaded in a secondary JSON file.
- Do not treat a fresh Windows or macOS modified date as proof that EXIF was lost.
- Do not overwrite every photo simply because a JSON file is present.
- Keep the untouched Takeout export until you have verified a migrated library.
What the Google Photos JSON sidecar can add
A Takeout sidecar can contain Google-specific values such as photoTakenTime, creationTime, descriptions, and location evidence. Those fields can be useful when a screenshot, social-media image, scanned photo, or other source never had a reliable embedded capture date. They can also differ from existing EXIF, so the sidecar should be compared rather than blindly copied.
- photoTakenTime is the stronger capture-time candidate when it exists.
- creationTime can describe Google ingestion or upload timing and should be treated as a fallback requiring review.
- GPS is sensitive metadata; restore it only when you actually want location retained.
Match JSON to media conservatively
Takeout sidecar names are not always a perfect one-to-one mirror of media filenames. A safer matcher stays inside the same extracted folder and prefers strong evidence: the JSON title matching a media filename, then the sidecar filename itself, then a constrained normalized-name match. If more than one media file remains plausible, stop and review instead of applying metadata to the wrong photo.
- Newer exports can use names ending in .supplemental-metadata.json.
- Long filenames and duplicate markers can complicate name matching.
- Do not search the entire archive for a vaguely similar filename when several album folders can contain copies.
Choose a date policy that preserves evidence
An embedded DateTimeOriginal or equivalent camera capture date should normally win because it travelled with the original media. When that value is missing, a uniquely matched Google photoTakenTime can fill the gap. If the two dates differ by more than a day, treat the row as a conflict rather than silently replacing one source with the other.
- A UTC timestamp can preserve an instant even when the original local timezone is unknown.
- Changing a file's filesystem modified date is different from writing photographic EXIF capture metadata.
- Creation-time fallback should be opt-in because it can represent ingestion rather than capture.
Exact duplicates need byte evidence, not filename guesses
Album copies and repeat Takeout exports can produce duplicate-looking files, but same names or same dimensions are not proof. A defensible exact-duplicate check first groups equal byte lengths and then compares SHA-256. Even then, a rescue workflow should report duplicates before deleting anything.
- Edited or resized versions normally have different bytes and remain separate.
- Live Photo image/video companions are different files, not duplicates.
- Keep duplicate removal as a later deliberate cleanup step after migration review.
Repair missing JPEG EXIF narrowly and losslessly
A conservative browser workflow can insert a minimal EXIF block into a JPEG that has no EXIF block at all, using a uniquely matched photoTakenTime. Because the JPEG's compressed pixel stream does not need to be decoded and re-encoded, this kind of insertion can preserve the image pixels byte-for-byte while adding metadata around them. Existing EXIF blocks deserve format-aware editing rather than a second competing EXIF structure.
- Restore GPS only when explicitly enabled.
- Keep PNG, WebP, HEIC, AVIF, TIFF, and video bytes unchanged unless a format-specific metadata writer is separately validated.
- Record every changed file and its new checksum in the audit package.
Process very large Takeout libraries in batches
Takeout archives can be hundreds of gigabytes or more. Browser hashing and ZIP creation require memory, so audit and rescue work should be divided into extracted year, album, or folder batches rather than loading a whole multi-terabyte archive at once. Google itself notes that large Takeout exports can be split into multiple archive files.
- Extract with a trusted desktop archive tool first.
- Audit a bounded folder, save the reports, then continue with the next batch.
- Keep consistent rescue options across batches and retain the original directory structure or audit CSV for traceability.
References and source documentation
Platform guidance and operating-system behavior can change. Review the linked source when a current requirement matters.
Google Photos Help — How to download your Google data ↗