Every way to move your photos out of Google Photos, compared

A migration that deserves the name does three things. It moves your whole library, not a hand-picked subset. It keeps every photo's capture date and location, so 2015 still sorts under 2015 at the destination. And it lands the photos usable — as browsable files, not as a pile of zip archives.

Two Google decisions shape every route. First, on March 31, 2025 Google shut off the API scopes that let third-party apps read your library — apps now see only what you hand them through a picker, or what they uploaded themselves. (One loophole survives: a browser extension driving your own logged-in session sees whatever you see. Route 4 lives there.) Second, Google Takeout, the main full-library exit that remains, splits your metadata: originals keep the EXIF embedded in the file, but anything Google holds in its database — dates and locations you fixed in the app, descriptions, and the metadata of photos stored in “Storage saver” quality — travels in little .json sidecar files with famously inconsistent names, while the files themselves get stamped with the export date. Every honest tool comparison is really about who deals with those two facts, and how.

Under the Data Transfer Initiative, Google runs a direct, server-side transfer — find it in Takeout as “Transfer a copy of your data”. Request it, pick a destination, and Google copies your photo library across without a byte touching your machine. It's free, small libraries land within a day (multi-hundred-GB ones take days), and the destination list is longer than most people think: iCloud Photos, Microsoft OneDrive, Flickr, and SmugMug. For standard formats, embedded EXIF — timestamps, camera settings, GPS — survives the trip.

Then the fine print, and here it bites. The video half of Live/Motion Photos is stripped (unless you convert each one to a video inside Google Photos first). Everything you fixed inside Google Photos — corrected dates, manual locations, descriptions — stays behind, because it lives in Google's database, not the files. Photos stored in “Storage saver” quality can arrive without embedded dates for the same reason. Locked Folder content, Trash, and generated Memories don't transfer, and the service is unavailable on Workspace, child, and Advanced Protection accounts.

One more thing the help pages won't tell you, but our own testing did: it's a black box, and not always a reliable one. Once the job is queued there is no progress view, no percentage, no log — you wait, for hours or days, until an email arrives. When we ran it ourselves the transfer failed outright several times in a row, and the failure email says nothing beyond “try again”: no reason, no indication of what did or didn't make it across. It may well succeed on a retry, but plan for the possibility of babysitting a multi-day loop, and count your photos at the destination before trusting the result.

MultCloud, CloudsLinker, cloudHQ, CloudFuze and a shelf of similar services — plus the Chrome extensions most of them publish as storefronts (“Transfer Google Photos to iCloud” in the Chrome Web Store is a MultCloud frontend) — all sell the same promise: connect two clouds, click transfer, done. Before March 2025 that promise mostly held. Then Google's API change cut every one of them off from your library.

What remains is a picker: in MultCloud today, you click “Add More Photos” and manually select images through Google's chooser, batch by batch. For a dozen albums, workable. For a 50,000-photo library, it isn't a migration tool anymore — and the services' own tutorials now quietly route you through Google Takeout instead, at which point they're moving your zips, not your photos, with the dates still buried in the sidecars they don't read.

The pricing predates that reality: the free tier covers 5 GB of traffic a month, and paid plans run $19.99/month for 100 GB, $59.99/year for 1.2 TB, up to $119/year unlimited (or a $249 lifetime deal). Two things users report on top: traffic is deducted for failed transfer jobs too — there are documented cases of 200 GB of paid quota burning down on a 104 GB library that never finished — and big many-file folders crawl. Real money, for a transfer that either can't see your library or moves it with the metadata problem intact.

When you request a Takeout export, Google offers to deliver it straight into Drive, OneDrive, Dropbox, or Box instead of emailing you download links. People reasonably read that as “transfer my photos to OneDrive.” It isn't. It's a courier: what arrives at the destination is the export itself — a stack of zip archives (parts configurable from 1 to 50 GB; pick 50 GB, or a 500 GB library arrives as 250 fragile 2 GB pieces) with the sidecar metadata still detached.

As a delivery mechanism it's genuinely useful (emailed links expire after about a week, and each archive part allows only five download attempts — sending to a cloud sidesteps both). But nothing has been unpacked, deduplicated, or date-fixed. Your photos are stored at the destination, not usable there. Something still has to do the real work — which brings us to the remaining routes.

A newer category sidesteps both Takeout and the API wall: extensions that ride along in your own logged-in browser. Proper Takeout (Chrome and Edge, €24.99 one-time or €4.99/month ex VAT, first 100 items per session free) is the polished example. You open Google Photos, pick your library, an album, or a search result, and it downloads the originals to your disk — with dates and locations embedded into the files during export. No zips, no sidecars, year/month folders as it lands, and — uniquely on this page — it captures your in-app edits too, because it reads the same session state you see. Pro adds incremental exports, so a refresh only fetches what's new — the thing Takeout never learned.

The trade-offs are structural. Your browser does the hauling: the tab stays open while your bandwidth pulls the library down (multi-hundred-GB exports strain browser memory), and everything lands locally — if your destination is cloud storage, uploading is still your job. The whole category scrapes Google's private web interface rather than a supported API: an unannounced redesign breaks it until the developer ships an update, hammering your own session can brush against Google's anti-automation limits, and these are small tools with short track records (Proper Takeout counts a few hundred users and a handful of five-star ratings). Others in the niche cut harder corners — Quiver Photos ($50) bundles its own Chromium browser and has you type your Google password straight into it, which we wouldn't. Good route for a local, organized copy without the Takeout dance; half a route for a cloud-to-cloud move.

The self-reliant route: download the Takeout archives, unpack them, run a tool that merges each sidecar back into its photo, then bulk-upload the result with something like rclone. Everything here is free, and when it works, it works exactly as well as anything commercial. The honest inventory of the toolbox, mid-2026:

• GPTH (GooglePhotosTakeoutHelper) — the classic, 5,500+ GitHub stars, and a trap in 2026: last release September 2023, commits ended January 2025, dozens of issues unanswered. It never wrote EXIF at all — it sets filesystem timestamps, discards descriptions, and chokes on Google's newer .supplemental-metadata.json sidecar names. If you go this way, use the maintained Xentraxx fork instead.
• GoogleTakeoutFixer — the actively-maintained successor (launched 2026, Go). Writes real EXIF — DateTimeOriginal and GPS, via ExifTool under the hood — sorts into year/month folders, symlinks album copies instead of duplicating them, and ships a Windows GUI alongside the Mac/Linux CLI.
• ExifTool — the power tool underneath half the ecosystem. With a well-crafted command it merges sidecar JSON into EXIF flawlessly; crafting that command around Takeout's quirks — truncated sidecar filenames that break naive matching, missing timezone offsets, edited-photo duplicates, split Live Photos — is the actual work.
• rclone — the bulk uploader of choice for S3, B2, OneDrive, Dropbox and nearly anything else, resumable and scriptable. One clarification post-API-change: its Google Photos backend is broken (it can no longer read your library), but as the upload leg of a Takeout workflow it's as good as ever. (Migrating to Immich? Its community tool immich-go reads Takeout zips directly — even the new sidecar names — and restores albums and partner shares; see our leaving-Google guide. Ente's desktop app has a comparable built-in Takeout importer.)

Budget for it honestly: two to three times your library size in free disk (500 GB library ≈ 1–1.5 TB free), a long evening if everything goes right, a weekend when it doesn't, and re-doing the whole dance every time you refresh the backup.

The desktop middle ground: if you want the DIY control without the command line, Metadata Fixer ($39 one-time, Mac/Windows/Linux, free trial up to 100 files a run) is the maintained GUI for the sidecar-merging step — and a capable one: it reads the Takeout zips directly without pre-extracting, resolves the truncated and cross-zip sidecar names that break scripts, re-pairs split Live Photos, and fixes timezones. You still download the export, still need the disk space, and still upload the result somewhere yourself — it fixes the metadata, not the logistics.

PhotoBridge exists because route 4 is the right idea with the wrong amount of labor. You point it at the Takeout archives in your Drive; it unpacks them in the cloud, merges every sidecar's date and location back into the photo's real EXIF, skips the duplicates Takeout loves to include, survives interruptions, and uploads the result — organized by date — to OneDrive, Dropbox, Amazon S3, Backblaze B2, or any S3-compatible storage (Wasabi, Storj, iDrive e2, MinIO). Nothing downloads to your computer, and a finished migration comes with a report showing exactly what moved.

It's free to try on part of your library (2 GB), and a full migration is a one-time $19 pass — no subscription. Because it works from the sidecars, the dates and locations you fixed inside Google Photos come along too — the thing Google's own transfer drops. The honest limits: it starts from a Takeout export (only Google's own transfer and your own browser session can bypass that), and it won't take you to iCloud — route 1 owns that.

Full disclosure, again: PhotoBridge is our product. The rest of this page works without it.

Moving to iCloud? Use Google's own transfer. Free, official, embedded EXIF intact. Nothing else in this guide — ours included — is the right tool for that job. Convert your Motion Photos to videos first if their movement matters to you.

Moving to OneDrive, Flickr, or SmugMug with a clean library? Google's transfer reaches those too, free. “Clean” is the condition: original-quality uploads, no dates or locations fixed inside Google Photos, Live-Photo videos expendable. If that's not your library — most long-lived libraries aren't — a Takeout-based route preserves what this one drops.

Comfortable with a terminal and have the disk space? DIY is genuinely fine: Takeout, ExifTool or GoogleTakeoutFixer, rclone to wherever you're going. Costs nothing but time; just skip the original GPTH (unmaintained, and it never wrote EXIF anyway), and test a sample before trusting any script with twenty years of dates.

Just want a hand-picked album moved? The picker-based cloud services still do that, and for small selections the free tiers suffice.

Want a local, organized copy on your own disk without the Takeout dance? Proper Takeout is the smoothest path there today — dates embedded, year/month folders, incremental refreshes on Pro. Just know you're leaning on an unofficial interface and a young tool; spot-check the output.

Whole library, to storage you own, without a weekend of work? That's the case we built PhotoBridge for: cloud-to-cloud from your Takeout, dates repaired, duplicates skipped, $19 once. Try the free tier on part of your library and check the dates yourself before paying anything.