Google Photos Export to Immich: Dates, Sidecars, Albums
How to get a Google Takeout export into Immich with the right dates. Covers immich-go, why dates break on a plain upload, and preparing files first.
You set up Immich, uploaded your Takeout folder, and the timeline shows everything on one day. Or you used immich-go and a few thousand photos still came in undated, and the log says hundreds of JSON files are missing.
Immich is a good place to land. The trick is getting the dates into a form it reads.
How Immich decides a photo's date
Immich reads EXIF DateTimeOriginal from images and the creation date from video containers. If neither exists, it uses the file's modified time. It also reads .xmp sidecars. It does not read Google's .json sidecars when you upload through the web interface, the mobile app or the CLI. Those files are simply unsupported and Immich logs an error for each one.
After a Takeout unzip, the file modified time is the moment you unzipped. So any photo without an EXIF date lands on that day. Screenshots, chat images, scans and anything you re-dated in Google Photos are the usual victims. Camera photos with intact EXIF are fine.
Route 1: immich-go
immich-go is a free command-line tool built for exactly this. It reads the Takeout zips directly, pairs each photo with its sidecar, uses photoTakenTime as the date, recreates albums from the album folders, and uploads to your server. It is the route the Immich community recommends, and it works well.
A basic run:
immich-go upload from-google-photos --server http://your-server:2283 --api-key YOURKEY ~/Downloads/takeout-*.zipPoints worth knowing. It handles the 2024 supplemental-metadata naming and the truncated names in current versions; if you see "JSON missing" for many files, update first. It uploads the file as-is and sends the sidecar date separately, so the date is stored in Immich's database, not written into the photo. If you later export from Immich or point another tool at the same files, the file itself still has no date. Run it with --dry-run first to see counts.
A missing-JSON count in the low hundreds on a big library is normal. Those are usually Live Photo clips, edited copies and files from old uploads that never had a sidecar. immich-go falls back to the file date for them.
Route 2: Fix the files, then upload any way you like
The alternative is to write the sidecar data into the files before they reach Immich. Then every upload path works, the dates travel with the files if you ever leave Immich, and an external library pointed at the folder indexes correctly.
With exiftool:
exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" \
"-DateTimeOriginal<PhotoTakenTimeTimestamp" \
"-GPSLatitude<GeoDataLatitude" "-GPSLatitudeRef<GeoDataLatitude" \
"-GPSLongitude<GeoDataLongitude" "-GPSLongitudeRef<GeoDataLongitude" \
-ext jpg -ext heic -ext png -overwrite_original .Videos need the QuickTime tags, and truncated or (1) sidecar names need extra passes. The merge guide walks through it.
Takeout JSON Metadata Fixer does this as a desktop app on macOS, Windows and Linux, including on the machine that hosts Immich.
Point it at the Takeout zips. It writes the real date and GPS into every photo and video, sets file dates to match, and sorts the output into year and month folders if you want. Two options matter for Immich. Leave Live Photos on "Keep the clip beside the photo" so Immich pairs still and clip on upload. And turn on "Write .json sidecars" if you plan to use immich-go afterwards; it writes a clean sidecar per file in Google's format, with the real date and coordinates, so immich-go has nothing to guess.
The result is a normal folder of dated photos. Upload it with the web interface, the CLI, or immich-go. Or add it as an external library and let Immich index it in place. The first 500 photos are free.
Albums
Takeout represents an album as a folder containing copies of its photos plus a metadata.json with the album name. immich-go turns those into Immich albums. If you go the fix-the-files route, you either upload the album folders too, which creates duplicates that Immich then deduplicates by hash, or you upload the Photos from YYYY folders and rebuild albums by hand.
Immich dedupes exact byte copies on upload. Once dates are written into the files, two copies of the same photo are still identical to each other, so the dedupe still works.
Checking the result
After the upload, open the timeline and scroll to an old year. Open a photo and look at the info panel; the date should match what Google Photos showed. Open the map. Photos with real GPS should appear. Photos that had 0.0, 0.0 in the sidecar should not appear in the ocean; if they do, your merge step wrote zeros, and you need to strip them with exiftool -gps:all= on the affected files.
If a batch is still wrong, Immich lets you select photos and edit the date in bulk from the web interface.
Frequently asked questions
Should I use immich-go or fix the files first?
Both work. immich-go is faster and rebuilds albums. Fixing the files first means the dates live in the photos, which matters if you use external libraries or might move again later. Some people do both: fix the files, then upload with immich-go for the albums.
Why does Immich show a time a few hours off?
The sidecar timestamp is UTC. When written into EXIF it becomes local time in your computer's zone, with no zone recorded. Immich then displays it as-is. Set your computer's zone to match the photos before merging, or adjust in Immich afterwards.
Immich says "Unsupported file" for every .json. Is that a problem?
No. It is telling you it ignored them. Either delete the sidecars before uploading or use immich-go, which consumes them.
Do I need to convert HEIC?
No. Immich reads HEIC and generates its own previews. Keep the originals.