Google Photos Takeout JSON files: what to keep before fixing dates

Keep the JSON files while you check the export

Do not discard the JSON files just because your photos open without them. A viewable picture and a well-described picture are different preservation goals. Before tidying a Google Photos Takeout export, keep an untouched copy of the downloaded archives, retain the extracted folder structure, and investigate a small working sample.

This guide addresses one specific problem: an export contains unfamiliar JSON files, and old photos appear under a recent date. The aim is to decide what needs investigation before renaming, importing or rewriting anything—not to promise a one-click metadata repair.

Separate three kinds of information

Google’s download documentation distinguishes a timestamp assigned by the operating system during download from original timestamps inside the media. It also says additional information, such as Google Photos comments, is exported into secondary JSON files. That is not a claim that every exported image has every field you expect.

A column simply called “Date” is too ambiguous for a repair decision. Record its full label and the application. An absent field means not found in this inspection; it does not prove the picture was taken on the download date. Likewise, an old date in a filename is a clue, not independent proof of capture time.

Set up a working sample without flattening the archive

Google notes that a large export can arrive in several archives. Confirm that you have downloaded the parts listed for your export before treating a missing item as lost. Recent library changes may also fall outside an export’s contents. Record the export request and download dates so you know which snapshot you are reviewing.

1. Preserve the delivery. Keep the downloaded archive files unchanged. Do not rename or delete their contents as your first organizing step.
2. Separate extraction from experiments. Extract into a fresh, clearly named location. If a file conflict or overwrite prompt appears, stop and investigate instead of choosing “replace all.”
3. Copy a small working set. Choose an older camera photo, a screenshot or edited image, and a video. Keep their relative folders and candidate JSON files together. These cases can reveal different gaps.
4. Write down what you copied. Record the original relative path and archive part. Do not merge everything into a single folder: repeated filenames would become harder to distinguish.

My photo-export review/
  downloads-kept-unchanged/
  extracted-kept-unchanged/
  working-sample/
  review-notes.txt

This is KYD’s suggested local arrangement, not a representation of Google’s archive structure. Three folders on one drive do not make three independent backups. Use the capacity guide to allow for archives, extracted files and working copies, and keep a separate recovery copy where appropriate.

Worked example: one “wrong date,” three different decisions

Invented observations for teaching—not a test of a real Google account: someone downloaded an export on October 8, 2026. Their file manager shows that day for all three sample files. They then inspect the media and candidate companion data without changing either.

The three files look identical under one file-manager date column, but they call for three different actions. A bulk command that assigns that column’s date to every media file would erase the distinction the review just uncovered.

In this example, one item needs no demonstrated capture-date repair, one remains unresolved, and one needs a context-preservation decision. None of those outcomes authorizes deleting the source library.

Inspect one item without rewriting it

1. Open the media itself. Use a trusted local viewer and its information panel. Note the complete field label, value and application version. If the viewer exposes no suitable field, record “not shown” instead of inventing a date.
2. Inspect candidate JSON as text. Use a local plain-text viewer without saving changes. Do not upload family photos or metadata to an unknown online “fixer.” Names, descriptions and location-related fields may be private.
3. Establish the association. Keep the original path, compare identifying information that is actually present, and consult documentation for the specific export or importer. A similar basename alone is not enough when several files share it. Do not assume every JSON file describes one photo.
4. Test the destination with copies. If you intend to use a photo organizer, import only the sample into a separate test library where possible. Compare the displayed dates and wanted descriptions. Ask whether the importer supports this companion format; the presence of a JSON file does not establish support.
5. Write a bounded conclusion. For example: “Photo opens; capture date displayed; description not imported; original export retained.” This is more useful than “metadata fixed.”

If two displays disagree, preserve both values and their labels. A different timezone display is one possibility, not an automatic diagnosis. Do not apply a library-wide time offset until you know what each field and application represents.

When a cleanup or repair should stop

• Several possible companions: preserve them and mark the association unresolved. A rename based on a guess can make a later match harder.
• Unreadable archive or extraction error: resolve that problem before reviewing metadata. A partial extraction is not a trustworthy inventory.
• An importer skips context: keep the original media and companion data even if you create a convenient browsing copy elsewhere.
• A proposed repair overwrites originals: do not run it on your only export. First understand which fields it writes and test reversible copies.

The Library of Congress’s personal-archiving guidance emphasizes keeping descriptions with photographs. The practical point here is not to preserve a particular file extension for its own sake: preserve the information you would otherwise lose about the image.

A metadata edit may change a file’s bytes even if its visible picture does not change. Use our local file copy checker on an untouched source and a plain copy when the question is copy integrity; its limit is 32 MiB per file. It does not interpret JSON, determine a correct date, or verify an importer. See how to interpret a mismatch before labelling an edited derivative corrupt.

Keep a review record you can use later

Download the blank text worksheet

The worksheet is an original KYD template, not a Google export parser or a certificate. You may save, adapt and print it for your own archive. Fill it out locally; this website does not receive your notes. Keep completed records private and never include passwords or recovery codes.

Done for this session means: the delivered archives are retained, each inspected field is identified, ambiguous associations stay unresolved, and the next action is written down. Before relying on the export as a recovery copy, continue with the non-destructive recovery drill. Do not delete originals merely because three samples passed.