You downloaded your Google Takeout. Now what?

Two clocks are running on that email. The download links stop working about 7 days after the export was created, and Google lets each archive be downloaded 5 times. A flaky connection that restarts a download counts against that five. So the first job is boring: get every part onto your disk, in one sitting if you can, and check that the sizes match what the Takeout page shows. A part that is a few hundred megabytes short of its siblings is a part that got cut off, and it will fail to open later.

Don't rename anything. The file names carry the export's timestamp and the part number, in the shape takeout-20260925T101502Z-001.zip, or takeout-20260925T101502Z-3-014.zip for a larger export. Every tool that can put your library back together, ours included, reads those numbers to know which parts belong to the same export and whether one is missing.

If your files end in .tgz and you are on Windows, they won't open with a double-click. Install 7-Zip, or choose zip next time; there is no advantage to tgz for photos. Mac opens both with the built-in Archive Utility.

Last thing before you unzip anything: check your free disk space. Unpacking needs as much room as the zips take, and if you plan to fix the dates on your own computer, tools that rewrite files need that space again. A 200 GB export on a 512 GB laptop is a real problem. Two of the three routes below never unzip on your computer at all, which is a large part of why they exist.

Every part unpacks into the same skeleton: a folder called Takeout, inside it Google Photos, and inside that two kinds of folder side by side. Photos from 2019, Photos from 2020 and so on hold everything, one folder per year. Next to them sits one folder per album you ever made. The album folders are copies: a photo that is in three albums is in your export four times. Add the-edited copies Google writes for anything you cropped or filtered, and an export is routinely twice the size of the library it came from.

Beside almost every photo is a small text file with the same name and a .json ending. Since late 2024 it is usually .supplemental-metadata.json, and when the photo's name is long, Google cuts the ending short in ways that vary from file to file. These sidecars are where Google kept the things it never wrote into the photos themselves: the capture date it worked out for screenshots and WhatsApp pictures, any date you corrected by hand, the location you added, your descriptions, your favourites. A photo and its sidecar don't always land in the same part, either; part 3 can hold the picture and part 7 its sidecar.

Two things are not in there, and people go looking for them. Albums that someone shared with you belong to that person and are not exported unless you saved the photos to your own library first. And Live Photos come apart: the still and its three-second video are two ordinary files now.

Google did not strip your dates. Unzipping did something simpler: your computer stamps every file it extracts with the moment of extraction, and that is the date Finder, Explorer, and every cloud's default file view sort by. A photo taken by a camera or a phone still has its real capture date inside the file, in the EXIF header, exactly as it was uploaded. The file browser is just not looking there.

The photos that are at risk are the ones that never had an EXIF date: screenshots, pictures saved from WhatsApp or the web, scans, and anything whose date you fixed by hand in Google Photos. For those, the only record of when they were taken is the sidecar. Lose the sidecar, or upload the photo without merging it, and that photo is dated today forever.

This matters because of how the clouds build their timelines. OneDrive's Photos view sorts by the EXIF date and falls back to the file's modified date when there is none. Dropbox's file list mirrors the modified date from your disk, while its Photos tab reads EXIF. So the whole game, whichever route you take, is: get every date into the photo file itself before the photo reaches the cloud. Everything else is logistics.

The right route depends on gigabytes and on how much of the work you want to do yourself. Here they are in the order most people should try them.

Route 1 · Upload the zips to PhotoBridge (up to a few dozen gigabytes)

Pick your destination, choose “Upload from this computer” on the Files step, and drop the zips in. They stream from your browser to our staging storage in 16 MB chunks, several at once, and a closed lid pauses rather than ruins the upload: pick the same file again and it carries on from the parts already sent. Once they are up, the migration runs on our side. Each archive is unpacked, every sidecar's date and location is merged into its photo, album duplicates are recognised and skipped, and the result is written into a clean year-and-month folder tree in your OneDrive, Dropbox or bucket. Nothing is unzipped on your computer.

The limit is your home connection. A typical fibre or cable plan uploads at 40 to 50 Mbps, which is about 5 MB a second in practice: an hour for 20 GB, a night for 50 GB, and the better part of a day for 100 GB even before anything goes wrong. Past roughly 50 GB, the second route is faster and kinder to your router.

Route 2 · Drag the zips into OneDrive or Dropbox and let PhotoBridge read them there (large libraries)

Install the OneDrive or Dropbox desktop app if you don't have it, and drag the zips into any folder it syncs. The app does the uploading: it runs in the background, survives sleep and reboots, and retries on its own, which a browser tab can't match for a 300 GB pile. Because you are moving a handful of large files rather than a hundred thousand small ones, you also sidestep the two traps that catch people who unzip first, described under route 3. When the zips have landed, connect that cloud in PhotoBridge and choose “In my OneDrive” or “In my Dropbox” on the Files step. It finds the parts, checks the numbering for gaps, and runs the same unpack-and-repair migration as route 1, cloud to cloud.

If you still have the option, there is an even shorter version of this route: request the export again and pick “Add to OneDrive” or “Add to Dropbox” as the delivery. Google then delivers the parts server to server and your connection never touches them. It costs you a second wait for Google, and saves you the upload entirely.

Route 3 · Do it yourself (any size, a weekend, no PhotoBridge)

Unzip every part into one folder, run a tool that merges the sidecars into the photos, delete the album duplicates, then upload the result with the cloud's desktop app. The tools are good in 2026. GooglePhotosTakeoutHelper is free, open source and command-line, handles the renamed sidecars and the album duplicates, and needs ExifTool installed for anything that isn't a JPEG. Metadata Fixer ($39, one time) does the same with a window and buttons and copes with multi-part exports by itself. FolioSort repairs dates, locations and favourites for free and charges for folder sorting. And ExifTool underneath them all will do anything, if you are comfortable writing the command yourself.

Two traps wait at the upload step, and both are documented by the clouds themselves:

• OneDrive counts the whole path. The cloud limit is 400 characters for the full path, and spaces and special characters count as their encoded form, so a space costs three. Takeout's long album names plus .supplemental-metadata.json endings reach that limit more often than you would think, and the desktop app reports it as a vague sync error. On Windows there is a second, lower limit of 260 characters for the local path.
• Dropbox counts files. Dropbox says its desktop app slows down past about 300,000 synced files. A ten-year library with its sidecars and album copies gets there. Delete the duplicates and the merged sidecars before you sync, not after.

Then the upload itself: the same 5 MB a second as route 1, but for the unzipped library rather than the zips, with the desktop app indexing every small file as it goes. Plan on days for a few hundred gigabytes, and expect the rest of the household to notice the upstream is busy.

Full disclosure: PhotoBridge is our product, and this guide is on our site. Route 3 works without it, and for a small library and a free weekend it is a fine way to go.

• Under about 50 GB: route 1. Upload the zips tonight, wake up to a sorted library.
• More than that, or a connection you don't trust: route 2. Drag the zips into the desktop app, let it work for a day or two, then point PhotoBridge at the folder. If you can still re-request the export, ask Google to deliver straight to that cloud and skip the upload.
• You like a terminal and have the weekend: route 3, with GooglePhotosTakeoutHelper, deleting the duplicates before you sync, and a wary eye on the path and file-count limits above.
• Whatever you choose: keep the original zips until you have opened a 2015 photo in the cloud and seen 2015 on it.