Takeout JSON
EN

immich-go Missing Sidecar? The Causes and the Fix

immich-go missing sidecar means it found no Takeout .json for a photo, so the date or GPS is lost. The five causes and how to fix them before upload.

immich-go reports a missing sidecar when it cannot find the Google Takeout .json file for a photo. The photo still uploads, but without the date, location and caption that were in that file. The usual causes are zip parts left out of the run, sidecar names that Google cut off or renumbered, and edited copies that never had a sidecar of their own. Give immich-go every part in one run, use a current release, and write the metadata into the photos first if some still fail.

Missing geotags have a second, separate cause: the sidecar exists but says 0.0, 0.0, which means Google had no location. Both are explained below.

Cause 1: not every zip part is in the run

A Takeout export arrives in numbered parts, and Google does not keep a photo and its .json file in the same part. If you run immich-go on takeout-001.zip today and takeout-002.zip tomorrow, a photo in part 1 whose sidecar is in part 2 counts as missing its sidecar.

Pass all parts at once. With current releases:

immich-go upload from-google-photos --server=http://your-immich:2283 --api-key=YOUR_KEY /path/to/takeout-*.zip

On Windows, run immich-go.exe in Command Prompt or PowerShell with the same arguments. If you unpacked the parts yourself, unpack all of them into one folder first and point immich-go at that folder. Check that no part is missing: a gap in the numbers, such as -011 then -013, loses every sidecar in -012.

Cause 2: the sidecar name does not match

Google names sidecars in several ways, and a tool must know all of them:

PhotoSidecar
IMG_1234.jpgIMG_1234.jpg.supplemental-metadata.json (since 2024) or IMG_1234.jpg.json (older)
PXL_20240311_183022711.jpgPXL_20240311_183022711.jpg.supplemental-metada.json (cut at 46 characters before .json)
IMG_1234(1).jpgIMG_1234.jpg.supplemental-metadata(1).json (the counter moves to the end)

immich-go handles these cases, but Google changed the naming in 2024, and older immich-go releases predate that. Update to the latest release before anything else. If a few names still fail, look in the folder: the sidecar is usually there under a name that starts like the photo's name. supplemental-metadata.json explained lists every naming rule.

Cause 3: edited copies

A photo edited in Google Photos comes out as IMG_1234.jpg and IMG_1234-edited.jpg, with one sidecar for the original only. In exports in other languages, the suffix is translated, for example -bearbeitet in German. The edited copy is reported as missing a sidecar even though the original's sidecar has everything it needs. Takeout duplicates and edited versions explains what to keep.

Cause 4: files that never had a sidecar

Some files have none in any export:

  • the video half of a Live Photo or Motion Photo,
  • some very old uploads,
  • files Google could not process.

For these, "missing sidecar" is correct and harmless when the file has its own EXIF date. Why some photos have no JSON file lists the cases.

Cause 5: the sidecars were deleted

If someone cleaned up the export before the upload and removed the .json files, every photo is missing its sidecar. The only way back is a new Takeout export.

Missing geotags: the 0.0 case

When Google has no location for a photo, the sidecar still has a geoData block, with latitude and longitude 0.0. That point is in the Atlantic Ocean, so a careful tool ignores it. Screenshots, chat images and photos taken with location off are in this group. There is nothing to restore; you can add a place by hand in Immich. Google Takeout missing location explains how geoData and geoDataExif differ.

How to see which files are affected

Run immich-go with --dry-run first. It reads the whole export and pairs files and sidecars without uploading anything, then prints a summary with its counts. Search its log file for the files without a sidecar and look at a few of them in the export folder. You will usually see one of the causes above.

The reliable fix: write the metadata before the upload

If Immich reads the date and GPS from the photo's own EXIF, the sidecar no longer matters. Write the .json data into the photos first, then upload a plain folder:

  1. Merge the sidecars into the photos with a tool that handles all naming cases.
  2. Check a few photos that had no date, such as screenshots.
  3. Upload with immich-go upload from-folder instead of from-google-photos, or with the Immich app.

For step 1, free options are exiftool and GooglePhotosTakeoutHelper Neo, both on the command line. Takeout JSON Metadata Fixer does it without a terminal on Windows and Mac.

It pairs every photo with its sidecar, including cut-off names, moved (1) counters and edited copies, writes the date and GPS into EXIF, treats 0.0, 0.0 as no location, and reports which files had no sidecar at all. The first 500 photos are free. immich-go vs Takeout JSON Metadata Fixer explains when you need which, and Google Photos export to Immich covers the whole move.

Frequently asked questions

Does a missing sidecar mean the photo is not uploaded?

No. immich-go uploads it. It only lacks the date, location and caption from the .json file.

Which date does Immich use for a photo without a sidecar?

The EXIF date inside the file if there is one. Otherwise a date from the file name or the file date, which after a Takeout is often the export day.

Should I rename the sidecars by hand?

Only for a handful. For more, update immich-go or merge the metadata into the photos first.

Are albums affected?

Usually not. immich-go builds albums from the album folders of the export, not from each photo's sidecar.