How to transfer Google Photos to Dropbox

For years, cloud-transfer services could plug into the Google Photos API, read your whole library, and copy it anywhere. On March 31, 2025, Google shut that door: third-party apps lost the ability to read your library. What's left is a picker where you hand an app photos a handful at a time. Fine for choosing prints, useless for a 60,000-photo archive.

The services built on that API are still ranking in your search results, still selling subscriptions, and still promising a direct Google-Photos-to-Dropbox sync. Read their instructions closely and you'll find the tell: somewhere around step three they quietly route you into Google Takeout, because Takeout is now the only door out of Google Photos that can see everything. We compared them all in a separate guide; the short version is that whatever you pick, your migration starts the same way.

All three start with the same five minutes: go to takeout.google.com, deselect everything except Google Photos, and request the export. The routes differ in where you send it and who does the cleanup afterwards.

Takeout can deliver your export directly into Dropbox: on the export screen, change “Transfer to” from download links to Add to Dropbox. Google then pushes the archives server-to-server into an Apps/Google Download Your Data folder. Nothing touches your home connection, and you can schedule a fresh export every two months for a year.

Know what you're getting: a shelf of compressed archives, not a photo library. A 200 GB library arrives as dozens of zip parts. The photos inside still have their metadata split across .json sidecars, and Dropbox's photo timeline can't see inside zips at all. Three practical warnings:

• Pick 10 GB parts, not 50 GB. The jumbo archives fail during generation and delivery far more often (multi-gigabyte zips also trip up many extraction tools), and a failed part means re-running the whole export.
• Mind the one-week window. An export that isn't delivered or downloaded within about 7 days expires, and large exports can already take days to generate. Make sure Dropbox has enough free space before you request the export, or the hand-off aborts.
• Don't unzip inside Dropbox's website. The web extractor routinely times out on Takeout-sized archives with their hundreds of thousands of small files. If you later want the photos unpacked, do it on a computer via the desktop app. That is Route B.

As a cheap, automatic backup of your Google Photos data, this route is good: zipped archives in your own Dropbox beat no copy at all. As a way to actually look at your photos in Dropbox, it isn't one.

The purist's route, and the only free one that ends with correct dates. Send the Takeout export to download links (or Drive), then, on a computer with enough free disk:

• Download every part and extract them all into one folder tree (7-Zip on Windows, Keka on macOS are the reliable choices at this size).
• Run a metadata fixer, either GPTH Neo (the maintained fork of Google Photos Takeout Helper) or ExifTool with a Takeout script, to merge each .json sidecar's date and GPS back into its photo. Use a current version: Google renamed and started truncating sidecar filenames in late 2024, which broke older scripts and tutorials, the original GPTH among them.
• Deal with the duplicates Takeout creates when a photo is in your albums as well as the main stream (fixers handle some of this; spot-check).
• Move the repaired folders into your Dropbox folder and let the desktop app upload them. The desktop client handles enormous uploads gracefully; the dropbox.com uploader caps out (350 GB per file) and struggles with hundred-thousand-file batches.

Budget a weekend, twice your library's size in free disk, and some patience with the fixer's edge cases. If that sounds like a satisfying project, it is one. If it sounds like the reason you've postponed this migration for a year, that's the next route.

PhotoBridge is Route B as a service, with the laptop taken out of the loop. You send your Takeout export to Google Drive (a delivery option right next to Dropbox's), connect your Dropbox, and it streams the export across: unpacking the split archives, merging every sidecar's date and location back into the photo's EXIF, skipping the album duplicates, and writing the result into a clean date-organized folder in your Dropbox. It resumes itself after interruptions and emails you a per-file report at the end.

The sidecar mess is the part we have spent the most time on: the renamed .supplemental-metadata.json files, the truncated filenames, the mismatched “(1)” copies. Our parser exists because these edge cases break naive scripts.

Full disclosure: PhotoBridge is our product, and this guide is on our site. Routes A and B work without it, and the comparison above is honest about when they're the better pick.

Search any forum for Takeout and you'll find the same despairing post: “every photo shows today's date instead of when it was taken.” The usual conclusion, that Google strips your metadata out of spite, is wrong, and understanding what actually happens tells you exactly what needs fixing.

What's intact: the photo files themselves. Takeout returns the exact bytes you uploaded. A camera photo with its capture date and GPS embedded in EXIF still has them, byte for byte.

What's misleading you: your computer. Unzipping stamps every extracted file with today's date as its filesystem date, and both your file browser and Dropbox's default view sort by that, not by the EXIF date inside the file. The library looks flattened to the export date while being mostly fine underneath.

What's genuinely at risk: everything Google kept in its database instead of your files. Dates you corrected in Google Photos, locations you added, and the capture times of the many photos with no EXIF at all: screenshots, WhatsApp and social-media saves, some messaging-app videos. Takeout ships all of that in the .json sidecar next to each photo, and only there. Skip the merge step and those photos really do fall to the export date, permanently. On a typical phone-era library that can easily be a fifth of everything you own.

So the test of any migration route is one question: does it put the sidecar data back into the files before they land in Dropbox? Route A doesn't (it parks the problem, zipped), Route B does if the fixer runs clean, Route C does automatically.

Check your library's size under your Google account's storage settings, then pick a plan with room to spare; during the move you may briefly hold both archives and unpacked photos:

Two quirks worth knowing before the photos arrive. Dropbox's photo timeline reads EXIF, so a properly repaired library sorts correctly there even when the plain file view shows extraction dates. Check the Photos tab before assuming anything went wrong. And Dropbox's web uploader and web unzipper are the wrong tools for a library-sized job: use the desktop app for bulk uploads, and never plan on unzipping archives inside dropbox.com.