Google Takeout JSON Sidecars: The Definitive Technical Architecture Guide

1. Why Does Google Takeout Separate Metadata into JSON Files?

To understand why Google Takeout generates sidecar files, we must examine how modern cloud storage infrastructure functions at petabyte scale. When you upload a picture from an Android device or iPhone to Google Photos, Google processes the file through an ingest pipeline:

1. Metadata Extraction: The ingestion server reads the photo's existing EXIF tags (shutter speed, focal length, GPS, timestamp) and indexes them into Google's distributed database (Spanner/Bigtable).
2. Cloud Editing & User Annotations: When you modify a date in the Google Photos interface, add a description, or adjust a location pin, Google does not rewrite the binary media file stored in Google Cloud Storage. Modifying multi-gigabyte or millions of distributed objects in place is computationally cost-prohibitive and risks bit-rot. Instead, edits are recorded as delta records in the database.
3. Export Packaging: When you request a Google Takeout export, Google's batch job packages your media files in their raw, immutable state, while dumping the database records as plain JSON sidecars.

While computationally efficient for Google, this architecture delegates the burden of metadata reconciliation to the end user.

2. The Anatomy of a Google Takeout JSON Sidecar

Every photo or video exported from Google Takeout is accompanied by a companion JSON document. If your photo is named IMG_2024.jpg, the sidecar is typically named IMG_2024.jpg.json.

Below is an authentic schema snippet showing the critical fields extracted during an export:

{
  "title": "IMG_2024.jpg",
  "description": "Family trip to Yosemite National Park",
  "imageViews": "4",
  "creationTime": {
    "timestamp": "1714582800",
    "formatted": "May 1, 2024, 5:00:00 PM UTC"
  },
  "photoTakenTime": {
    "timestamp": "1714578124",
    "formatted": "May 1, 2024, 3:42:04 PM UTC"
  },
  "geoData": {
    "latitude": 37.74557,
    "longitude": -119.59360,
    "altitude": 1218.4,
    "latitudeSpan": 0.0,
    "longitudeSpan": 0.0
  },
  "geoDataExif": {
    "latitude": 37.74557,
    "longitude": -119.59360,
    "altitude": 1218.4
  },
  "people": [
    { "name": "Sarah Connor" }
  ]
}

Notice the key distinctions in Google's schema:

• photoTakenTime vs. creationTime: creationTime reflects when the asset was uploaded or ingested into Google's cloud. photoTakenTime represents the actual shutter click timestamp. Using creationTime instead of photoTakenTime can cause photos taken years earlier to be misfiled under their upload year.
• geoData vs. geoDataExif: geoDataExif contains the original hardware GPS coordinates captured by the camera sensor. geoData contains user-edited or estimated locations added in the Google Photos interface.

3. Why Operating Systems & Image Viewers Ignore JSON Sidecars

Operating systems (Windows Explorer, macOS Finder) and photo management software (Apple Photos, Adobe Lightroom, Synology Photos) do not parse custom JSON sidecars created by third-party cloud services. They rely exclusively on established, international binary metadata standards:

• EXIF (Exchangeable Image File Format): Standardized by JEITA/CIPA (Standard CP-3451C / EXIF 2.32). Encapsulated in the JPEG APP1 marker segment (0xFFE1).
• TIFF Header Segments: Used in RAW camera files (Canon CR2/CR3, Nikon NEF, Sony ARW) and DNG digital negatives.
• QuickTime UserData / Atoms: Used in MP4 and MOV video containers (specifically the moov.udta.meta.keys atom hierarchy).

When you extract a Takeout ZIP archive onto your hard drive, the operating system assigns the current moment of extraction as the file system attribute: FileCreateDate. Because the image viewer detects no embedded EXIF date in an altered photo, it falls back to the file system creation date. Consequently, a photo from 2012 appears to have been taken today.

4. How Reconstructing EXIF Tags Works Losslessly

A common misconception is that fixing photo dates requires re-compressing or re-rendering the image. This is incorrect. In modern binary manipulation, image pixels and image metadata exist in completely separate segments of the file stream.

To repair a JPEG image:

1. The restorer reads the JPEG Start-of-Image (SOI) marker (0xFFD8).
2. It scans for the existing APP1 EXIF segment. If present, it parses the IFD0 (Image File Directory) and ExifSubIFD structures.
3. It maps the Unix timestamp from photoTakenTime.timestamp to the standard EXIF date format string: YYYY:MM:DD HH:MM:SS.
4. It updates or injects tag 0x9003 (DateTimeOriginal), tag 0x9004 (CreateDate), and tag 0x0132 (ModifyDate).
5. If latitude and longitude are present, it converts decimal degrees into sexagesimal rational fractions (Degrees, Minutes, Seconds) and writes the GPS IFD tags (0x0001 GPSLatitudeRef, 0x0002 GPSLatitude, 0x0003 GPSLongitudeRef, 0x0004 GPSLongitude).
6. The restorer writes the revised APP1 segment back into the byte buffer. The image compressed image bitstream (the actual photo pixels) remains untouched, guaranteeing bit-for-bit lossless output.

5. Comparing Solutions: CLI vs. Desktop vs. Browser

Users seeking to resolve this issue have three main avenues: