To import Google Takeout into Immich, export Google Photos as .zip parts, then run immich-go’s upload from-google-photos command against all of the parts at once. Immich’s own documentation recommends immich-go for Takeout imports; it reads Google’s JSON sidecars and restores the capture dates, albums, and GPS that a plain upload drops. Verify before deleting anything from Google.
The migration itself is four steps: export with Takeout, stand the server up before the archives arrive, import with a Takeout-aware tool rather than copying files in, and verify before you delete anything. The step people skip is the third one, and it is the one that quietly destroys years of dates, albums, and locations.
This is the failure mode worth understanding before you start, because it is silent. Nothing errors. The photos all arrive. They just land in your timeline dated the day you imported them.
Why a Plain File Copy Loses Your Metadata
Takeout does not always write your photo’s original timestamp, GPS coordinates, description, and album membership back into the image file’s EXIF. A large share of it is delivered in companion .json sidecar files sitting next to each image in the archive. Drag the folder of .jpg files into any photo server and the sidecars are ignored: the server falls back to the file modification date, which is the moment the archive was unpacked.
An import tool that understands Takeout reads those sidecars and applies the real values as it uploads. That is the entire difference between a migration and a mess, and it is why the Immich documentation points at a specific community tool for this job instead of its own generic uploader.
Which Tool Imports Google Takeout Into Immich?
Use immich-go. It reads Takeout’s JSON sidecars, recreates Google Photos albums, and works on the .zip parts without unpacking them, and it is the tool the Immich CLI page names for Takeout. Immich’s own CLI is fine for ordinary folders but documents no handling for Google’s metadata.
| Route | Reads Takeout JSON | Google albums | Unzip first? | What you install |
|---|---|---|---|---|
immich-go upload from-google-photos | Yes, matches each file to its sidecar | Recreated (--sync-albums is on by default) | No; .zip parts or an unpacked folder | One binary, no Node or Docker |
Immich CLI immich upload | Not documented | From folder names with --album | Yes | Node.js 22+ or the CLI Docker image |
| Web upload or an External Library | No | No; external libraries have no album mechanism | Yes | Nothing extra |
Can Immich Download Directly From Google Photos?
No. Neither Immich nor any other third-party app can pull a whole library out of Google Photos any more. Google removed the photoslibrary.readonly, photoslibrary.sharing, and photoslibrary scopes from its Library API after March 31, 2025; apps can now only list, search, and retrieve media they created themselves. Takeout is the bulk route left.
Step 1 — Order the Export
Go to Google Takeout and start by deselecting everything, then selecting Google Photos alone. A full-account export bundles in Drive, Mail, and everything else, which multiplies the download for no benefit. Photos also lets you narrow the export to specific albums if you only want part of the library.
Three settings on the export screen decide how painful the next day is:
- File type.
.zipopens on any machine without extra software..tgzis the alternative, and Google’s own guidance is that it may need additional software on Windows; on Linux or macOS it is a non-issue. Do not mix the two: immich-go’s best-practice notes recommend ZIP for every part. - Archive size. Takeout splits the export into parts at a size cap you choose, up to a documented maximum of 50 GB per archive, and anything above the cap arrives as multiple numbered parts. Larger parts mean fewer files to babysit; smaller parts mean a failed download costs you less. For a library of a few hundred gigabytes on a stable connection, the 50 GB option is the least work.
- Delivery. A download link by email is the default. Exporting straight into Drive, Dropbox, OneDrive, or Box is also offered, and sending the archives to cloud storage you already sync to the server can save a round trip through your laptop. Archives added to Drive count toward your Google storage, so you need free quota for the whole export.
Then wait. Google’s documented range is anywhere from a few minutes to a few days, with most people getting the link the same day they ask; a multi-hundred-gigabyte photo library is exactly the case that lands at the slow end. Order the export the day before you plan to do the work, not the morning of.
Step 2 — Download Promptly and Check the Set
Takeout download links are time-limited: archives expire after roughly a week, and each one can be downloaded five times before you have to request the whole export again. Do not order a 400 GB export and go on holiday.
When the parts arrive, confirm you have every one of them before unpacking — they are numbered, and a missing part is a silent hole in the library rather than an error. Verify each archive opens cleanly. A truncated download that unpacks halfway is the second most common way a migration goes wrong.
Keep the original archives until the whole migration is verified. They are your rollback.
Google Drive to Immich: Let the Server Fetch the Archives
If you chose Add to Drive, the parts land in a folder named Takeout in your Drive, and the Immich host can fetch them itself with rclone rather than through your browser. Create a Drive remote with rclone config (called gdrive here), then:
rclone copy gdrive:Takeout /srv/takeout -P
rclone copy skips files already identical at the destination, so a re-run after a dropped connection fetches only what is missing. rclone’s Drive documentation warns that its shared Google client ID stops working during 2026; create your own client ID and secret when the wizard asks. Delete the parts from Drive once they open cleanly on local disk.
Photos kept in Drive as ordinary files, not in Google Photos, need no Takeout: copy the folders down the same way and upload them with immich-go upload from-folder.
Step 3 — Stand Up Immich First
Have the server running and reachable before the import, not after. The requirements are modest but specific: 6 GB of RAM minimum with 8 GB recommended, 2 CPU cores minimum with 4 recommended, and a Postgres database that must sit on local SSD storage rather than any kind of network share. The library itself can live on bulk storage mounted into the container. Budget that disk for the export plus 10 to 20 percent, which is what the same page says thumbnails and transcoded video add on average.
If you have not built it yet, Immich vs Google Photos covers what the stack contains and what it asks of a host, and the self-hosted app picker and resource budget estimator will tell you whether it fits alongside whatever else you already run before you commit to the move.
One sizing note that catches people out: during a large import the server is doing thumbnail generation and machine-learning indexing on top of receiving uploads. A first import of tens of thousands of assets can keep a modest CPU busy for many hours after the transfer itself finishes. That is normal, it happens once, and it is not a reason to buy a bigger box.
Step 4 — Import With a Takeout-Aware Tool
Immich’s official CLI (npm i -g @immich/cli, Node.js 22 or newer) handles ordinary folders well, but for a Google Photos export the documentation explicitly recommends the community-maintained immich-go, a tool built to match photos with their JSON metadata.
Install immich-go and create an API key
immich-go is a single binary, with no Node and no Docker. The current release when checked in October 2026, v0.32.0 from June 25, 2026, added Immich v3 compatibility while keeping v2 working, so use it or newer against a current server. Builds cover Linux, macOS, Windows, and FreeBSD on both x86_64 and arm64:
tar -xzf immich-go_Linux_x86_64.tar.gz
sudo mv immich-go /usr/local/bin/
immich-go --version
Create the key in Immich under Account settings > API Keys > New API Key, one per user you are importing for. The installation guide lists 15 permissions across the asset, album, stack, tag, server, and user scopes. Pausing Immich’s background jobs during the upload, which immich-go does by default, also needs job.create and job.read on an admin-linked key.
Run it against every part at once
immich-go upload from-google-photos \
--server=http://your-server-ip:2283 \
--api-key=your-api-key \
/path/to/takeout-*.zip
Pass all the parts in the same run. A photo and its JSON sidecar can sit in different numbered archives (immich-go’s Takeout notes walk through exactly that case in a ten-part export), so importing one part at a time separates files from their metadata. Add --dry-run first to simulate the whole import, then do a real pilot on one album with --from-album-name="Vacation 2023" and look at it in the web app before turning the tool loose on everything.
Use the server’s LAN address and port 2283 where you can. Through a reverse proxy, large videos are the first uploads to hit its request-size limit; the Nginx Proxy Manager guide shows where to raise it.
Points worth knowing before the run:
- It reads the archives as-is. You do not have to unpack the zips, which saves an entire copy of the library’s worth of disk space.
- Albums, descriptions, and locations are reconstructed from the sidecar JSON rather than guessed from filenames.
- Re-runs are safe. Files are compared by SHA-1 checksum and existing ones are skipped unless you pass
--overwrite, so restarting an interrupted import does not double your library. - RAW+JPEG pairs and bursts can be stacked rather than cluttering the timeline as separate assets, with
--manage-raw-jpegand--manage-burst. - Junk is skipped by default. The tool ships with sensible exclusions for NAS and OS clutter such as
@eaDir/,SYNOFILE_THUMB_*,.DS_Store,.Spotlight-V100/, andRecently Deleted/, and--ban-fileadds your own patterns. - Embedded dates win. immich-go takes the date from EXIF first, then XMP, then Google’s JSON, then the filename. A scan or a camera with a wrong clock keeps its wrong embedded date; fix those in Immich afterwards.
- It is honest about its own status. The project describes itself as an early version and tells you to keep a backup copy of your files. Keep the archives.
Flags that change a Takeout import
Defaults from the upload command reference:
| Flag | Default | Effect on a Takeout import |
|---|---|---|
--sync-albums | true | Recreates named Google Photos albums |
--include-untitled-albums | false | Skips untitled albums, which Takeout can lump into one folder |
--include-unmatched | false | Leaves out files with no JSON sidecar |
--include-trashed | false | Leaves Google’s trash behind |
--people-tag | true | Turns Google’s people names into people/Name tags |
--takeout-tag | true | Tags every asset with the Takeout timestamp |
Parallelism defaults to one task per CPU core (--concurrent-tasks, 1 to 20). For a library over 100,000 photos the best-practice guide suggests --concurrent-tasks=4 --client-timeout=60m --on-errors=continue --session-tag; on a NAS or low-power server it drops to 1 or 2 tasks with a 180-minute timeout.
Step 5 — Verify Before You Delete Anything
Count the media in the export rather than eyeballing it. Without unpacking anything:
for z in takeout-*.zip; do unzip -l "$z"; done \
| grep -ciE '\.(jpg|jpeg|heic|png|gif|mp4|mov)$'
Compare that against the asset count Immich reports on the server once indexing has settled. The two will rarely match exactly — the archives also carry .json sidecars and other non-media artifacts, and the importer skips its default junk list — but they should be close, and a gap of thousands means something went wrong.
If Immich comes up short, check the defaults first: files without a sidecar and Google’s trash are skipped unless you add --include-unmatched or --include-trashed, and a re-run uploads only what is missing. If thousands are still absent, the best-practice guide says some Takeouts arrive incomplete; request a fresh one.
Then spot-check the things that break silently:
- Dates. Open the oldest photos you own. If the timeline puts your 2009 holiday in the current month, the sidecars were not read and the import needs redoing.
- Albums. Confirm a handful of albums exist with roughly the right contents.
- Locations. Open the map view. A library with GPS data should light up; an empty map means metadata was lost.
- Motion photos and live photos. These arrive as paired files and are the fiddliest category. Check that a few play rather than showing as stills plus orphan video clips.
- Edited versions. Google stores an edited copy alongside the original for photos you have retouched. Decide whether you want both, and check which one landed in the timeline.
Step 6 — Do Not Delete From Google Yet
The last step is the one to be slow about. Until the library exists in at least two places you control, Google is still your off-site backup, and it is doing that job for free while you decide.
Get a real 3-2-1 backup strategy running first, covering both the photo files and a dump of the Immich Postgres database — the database is where albums, faces, and everything the import just reconstructed actually lives. Restore a test file from that backup and confirm it opens. Only then consider clearing the Google copy, and even then, keeping the original Takeout archives on a cold external disk costs almost nothing.
Then Switch On Phone Backup
Once the historical library is in and verified, open the Immich mobile app, choose the device albums you want covered on the backup screen, and enable backup. From that point the server is the destination for new photos and Google is out of the loop.
If you are still weighing whether Immich is the right destination at all, all five self-hosted Google Photos alternatives compared sets it against Ente, PhotoPrism, Nextcloud Memories, and LibrePhotos — and if you already run Nextcloud, for instance on a Raspberry Pi, the Memories app is a lighter destination for the same export. If Photos is the first Google service you are leaving, self-hosted apps to replace Google services covers what usually goes next.
FAQ
can i use the immich cli to import google takeout?
You can, but expect to lose the metadata Takeout keeps in JSON sidecars. The official immich upload command, which needs Node.js 22 or newer or its Docker image, documents no Google sidecar handling, and Immich’s CLI page itself points Takeout users to immich-go. Keep the official CLI for plain folders and use immich-go for Takeout archives.
why are my google photos dates wrong in immich?
Wrong dates almost always mean the JSON sidecars were never read: a generic uploader sent the files and Immich fell back to the file modification date, the moment the archive was unpacked. Delete those assets, empty the trash, and re-import the original archives with immich-go, which applies each sidecar’s capture date when the file lacks one.
do google photos albums transfer to immich?
Yes, named albums do. immich-go’s --sync-albums option is on by default and recreates each Google Photos album from the album folders and metadata in the Takeout. Untitled albums are skipped unless you add --include-untitled-albums, and even then they may not rebuild cleanly, because Takeout can drop every untitled album into a single folder.
does immich-go work with immich v3?
Yes, from immich-go v0.32.0, released June 25, 2026, which added full Immich v3 compatibility and still works with v2 servers. It reads the server version at startup and adapts. If you downloaded immich-go before that release, replace the binary before importing into a current v3 server such as v3.3.1.