MetadataViewerLOCAL PHOTO TOOLS / GOOGLE TAKEOUT
Google Takeout photo date repair
Compare your JPG photos with their JSON sidecars. See what differs, choose what to change, and download repaired copies. Your originals stay untouched.
1. Choose a small batch
Extract your Takeout ZIP first. Select photos and JSON together, or add them separately. Up to 100 files, 30 MB per JPG, 1 MB per JSON, 150 MB total.
Old .json and newer .supplemental-metadata.json names are supported. ZIP, HEIC, PNG and video repair are not supported.
Choose files to start. Nothing is changed automatically.
2. Match and review every change
Only exact, unique filenames are paired automatically. Choose a sidecar for ambiguous or renamed files. Existing capture dates are kept unless you explicitly select a replacement.
New dates use UTC (+00:00). The original capture timezone cannot be recovered from a Unix timestamp. An app that ignores the offset may show a different clock time.
JSON files and input issues
3. Create copies
Previewed changes apply to EXIF DateTimeOriginal and OffsetTimeOriginal. Old capture sub-seconds are removed from the active date fields. Digitized, modified, GPS, XMP and other metadata are kept.
When you may not need a repair
A recent “created” or “modified” date in Finder or Explorer does not mean a photo lost its original capture date. Those filesystem dates can reflect extraction, copying or downloading. Check the embedded EXIF capture date first. If it is correct, keep it; a different file date alone is not a reason to rewrite the photo.
This tool shows the last-modified date supplied by your browser as a separate value. Browsers do not reliably expose the original filesystem creation date, and a download cannot preserve all filesystem timestamps. The repair targets the date inside the JPG.
Which JSON date is used?
photoTakenTime.timestamp is the only repair source. creationTime is shown separately as a Google Photos creation or added-time reference; it is never substituted for a missing capture date. Human-readable JSON date strings are not used because their formatting and timezone can be ambiguous.
Takeout photos can already contain EXIF. This is not a blanket metadata restore: it does not copy JSON titles, descriptions, locations, albums or people into a photo. If your export contains an edited copy or several similarly named photos, inspect the image and its sidecar before deciding which pair belongs together.
Why some pairs need your choice
A sidecar may have a truncated filename, a title that differs from its filename, or a duplicate name from another folder. These are suggestions, not proof. No match is guessed. Each JSON can be selected for only one photo in the batch; conflicts block export until you choose another JSON or leave the photo unmatched. File numbers distinguish duplicates when the browser supplies no folder paths.
What is preserved?
The JPEG image stream is copied without recompression. Existing unrelated metadata payloads remain in the file; the active EXIF directory points to the reviewed capture date. This preserves old bytes too, so it is not a privacy scrubber. XMP dates are not synchronized and may still differ in apps that prefer XMP.
Malformed or oversized EXIF, multiple EXIF blocks, Content Credentials containers and multi-picture JPEGs are not repaired. Changes to metadata can affect provenance, so signed images are rejected. Keep your original Takeout archive as your backup, and check copies in the photo app you plan to use.
Browser and batch limits
Designed for small batches in desktop Chrome; that is the browser tested for this release. Other browsers and mobile downloads are not independently verified. Files stay in this tab's memory and are cleared when you reload or close it. After creating copies, download individual JPGs or a ZIP with a result list covering successful, skipped and failed items.