Tutorial — Monday, September 21, 2026

Getting Your Photo Library Out of the Cloud — With the Dates Still Attached

Exporting fifteen years of Google Photos or iCloud, and repairing the metadata the export quietly leaves behind.

GadgetGlow Bytes Editorial

Published September 21, 2026 · 8 min read · How we work

Somewhere in your Google or Apple account sits a folder holding every photograph you have taken since roughly 2010. It is probably the most valuable thing you own that has no physical form, and it lives in one place, behind one password, governed by one company's terms of service.

Getting a copy out is not the hard part. Both companies will hand you the files on request, free, and the process is well documented. The part nobody warns you about is that the copy you get back is not quite the same object you put in. The pictures survive intact. The information about the pictures only partly does. Dates go missing. Albums flatten into folders. Photos you edited arrive orphaned from the record of when they were taken.

This is a tutorial for doing it properly: one afternoon of setup, one overnight download, one verification pass. It assumes a library in the tens of thousands of files — the scale at which these problems stop being curiosities and become a decade of holidays filed under today's date.

First, understand what an "export" actually is

A photo in a cloud service is not really a file. It is a database row, and the image is an attachment to that row. Everything the service knows — the album it belongs to, the caption you typed, the faces it recognised, the location it inferred, who you shared it with — lives in the row, not in the JPEG.

So when you ask for your data back, you get two things. Google's own help documentation puts it plainly: your operating system may assign the downloaded file a new timestamp, while the original timestamp remains "preserved in the metadata embedded within the files"; and "any additional metadata that isn't from the original file, like comments within Google Photos, are downloaded to a secondary JSON file." That secondary file is the sidecar in the graphic above.

In practice the split is messier than that description suggests. An ecosystem of open-source repair tools exists precisely because, for a meaningful share of files, the embedded date is absent or wrong — screenshots, images saved from messaging apps, anything re-encoded on the way in, and above all anything you edited inside Google Photos. According to the maintainers of google-photos-exif, a file exported as foo-edited.jpg arrives with no sidecar at all — neither foo-edited.json nor foo-edited.jpg.json. We have not tested this ourselves; it is a well-replicated report across several independently maintained projects.

Apple's route works differently and, on this specific point, better: exporting "Unmodified Originals" gives you the file as captured, with its original embedded metadata, and no sidecar to reunite. The trade-off is that Apple gives you far less structure around the files.

Prerequisites

Free disk space of roughly 2× your library size. You need room for the compressed archives and the extracted files at the same time before you can delete the archives.
A destination drive you trust. If it will move between a Mac and a PC, format it exFAT. This should not be your only copy — see the note at the end.
ExifTool, Phil Harvey's free command-line metadata tool, if you are taking the Google route. It is the standard instrument for this job and every repair script listed in our sources wraps it.
Two evenings and a wired connection if you have one. The download is the long pole; a 400 GB library is an overnight job on most domestic connections.
Cost: nothing, unless you need to buy the drive.

Clock is running Google states that a Takeout archive expires in about 7 days and that each archive may be downloaded 5 times. Do not request the export until you have the disk space ready and a free evening ahead of you.

The four routes, compared

Route	What you get	Metadata	Practical ceiling
Google Takeout	Zip or tgz archives, albums as folders	Sidecar JSON, repair pass needed	Whole library; archive expires ~7 days
Mac Photos app	Files exported to a folder you choose	Embedded, no repair needed	Whole library; needs local disk for all originals first
iCloud.com	Direct download, no app needed	Embedded; format is selectable	Apple states 1,000 items per selection
iPhone Share sheet	Export to Files or external storage	Embedded ("Unmodified Originals")	Small batches only

Compiled by GadgetGlow Bytes from Google and Apple support documentation, verified September 21, 2026.

The steps

If you are on Google Photos

Deselect everything first. At takeout.google.com every product you use is pre-selected. Clear them all and tick only Google Photos. A combined export of Photos, Drive and Mail is slower to build, larger, and more likely to split.
Choose .zip, and set the archive size to 50 GB. Google's documentation is explicit that archives larger than your chosen limit are split into multiple files, and that picking the 50 GB cap "decreases the possibility that your archive will be split." Fewer parts means fewer ways for this to go wrong.
Pick a delivery method. Email link is simplest. "Add to Drive" helps if your connection is unreliable, but the archive counts against your Google storage while it sits there.
Wait. Google says this takes from a few minutes to a few days, and that most people get the link the same day.
Download every part before extracting anything. This is the most common way people corrupt an export. A split archive is one zip divided across files; extracting part 1 alone produces truncated images and a directory that looks complete but is not.
Extract them together, into one folder tree.

If you are on iCloud Photos

Open Photos on a Mac, then Photos → Settings → iCloud, and select "Download Originals to this Mac." Apple's support page is clear that this is what pulls the full-resolution files down; the alternative, "Optimize Mac Storage", deliberately keeps smaller versions locally.
Leave it plugged in and on Wi-Fi until it finishes. For a large library this genuinely can run overnight or longer.
Select all, then File → Export → Export Unmodified Original. "Unmodified Original" means the file as captured — HEIC, RAW, the original MOV — rather than a re-encoded copy. This is the option you want for an archive.
No Mac? Use iCloud.com, select photos, then More Download Options → Unmodified Originals. Apple documents a limit of 1,000 items per selection, which makes this workable for a few thousand photos and painful beyond that.

The repair pass (Google only)

Copy the extracted folder before you touch it. ExifTool's -overwrite_original flag means exactly what it says, and there is no undo. Work on the copy.

The pass reads each sidecar's photoTakenTime and writes it into the image's own DateTimeOriginal field, so the date finally lives inside the file, where every photo viewer looks for it. ExifTool reads tags from JSON natively; its -tagsFromFile option is documented for exactly this kind of per-file import.

Then face the naming problem. Since around late 2024 Google has appended .supplemental-metadata.json to sidecar names rather than a plain .json, and that suffix gets clipped when the total filename runs long — producing real-world names like image1.jpg.supplemental-metada.json and image1.jpg.sup-meta.json. A naive one-line command matches none of these. Reports of the exact character limit differ — the ExifTool forum discussion of the naming change and various tool authors cite different figures — so do not hard-code a number. Either run several passes with different suffix patterns, or use one of the maintained helpers that already enumerate the variants.

Older exports with plain .json sidecars are inconsistent too: the same library can contain both IMG123.jpg.json and IMG123.json for the same kind of file.

What can go wrong, and how to recover

You extracted part 1 and got broken images. Delete the extracted tree, re-download the missing parts, and extract all parts together. Nothing is lost; the archive is still on Google's side until it expires.

The archive expired mid-download. Request a new one. Google is explicit that an expired archive does not mean the data expired — it is regenerated from your live library.

Every photo now shows today's date. That is the filesystem timestamp, not the photo's. Point your viewer at the EXIF date rather than the file date, then check whether the repair pass actually landed using the verification step below.

Your photo count is much higher than expected. Albums export as folders, and a photo in three albums appears in three folders. This is duplication by design, not corruption. Do not run a deduplicator until you have decided whether you want the album structure preserved — deduplication will silently dissolve it.

Live Photos arrived as two files. A HEIC and a MOV side by side is the expected shape. Keep both; most viewers recombine them on import.

ExifTool reported errors on hundreds of files. Usually unmatched sidecars. Read the filenames it skipped — you will almost certainly find the truncation variants described above, or the -edited orphans, which have no sidecar to match in the first place.

How to verify it actually worked

An unverified archive is a hope, not a backup. Four checks, in order:

Count the files

Count missing dates

Sort by date, look

Checksum the copy

Count the files in the extracted tree and compare against the item count your cloud service reports. Expect the export to be higher, because of album duplication, not lower. Lower means something did not download.

Ask ExifTool how many files still have no capture date. Run it recursively with a condition that matches files where DateTimeOriginal is absent, and count the results. Run it once before the repair pass and once after. If the number barely moved, your sidecar pattern did not match — go back to the naming problem.

Open the folder in any viewer sorted by capture date and look at both ends. The oldest items should be genuinely old. A wall of files clustered on the day you ran the export is the failure signature.

Checksum after copying to the backup drive. Generate hashes at the source, copy, verify at the destination. Large copies of hundreds of thousands of small files do fail silently, and this is the only check that catches it.

When not to do this

Skip the ExifTool pass entirely if you are Apple-only. "Export Unmodified Original" already gives you files with their metadata inside. Adding a repair pass to a library that does not need one is a way to break things.

Do not start if you have nowhere to put the result. An export sitting on the same laptop as the originals has improved nothing.

Do not cancel cloud storage on the strength of a completed download. Cancel after verification passes. The gap between "the files are here" and "the files are intact and dated" is exactly where people lose things.

And never run the repair on your only copy. The procedure rewrites metadata in place across tens of thousands of files. If it fails at file 30,000, you want the untouched extraction still sitting there.

Our Read

The sidecar file is not a bug, and reading it as one misses what it tells you. It is the visible seam of a design decision made years ago across the whole industry: the photograph stopped being the record, and became an attachment to the record. Faces, albums, captions, shared state, the search index — none of that has anywhere to live inside a JPEG, so it lives in a database row instead. Ask for your data and you get the attachment, plus a dump of the row, and the work of reuniting them is yours. Data-portability rules oblige a company to let your data leave; they say nothing about it arriving usable, and that gap is precisely the space the repair-script ecosystem has grown into. That a dozen actively maintained open-source projects exist to reconcile one company's export format with itself is a fair measure of how wide the gap has become. The practical lesson generalises well beyond photos: judge a service not by whether it has an export button, but by whether its export round-trips. Before committing another decade of anything to a platform, ask what importing its own export would look like.

What we still don't know: the exact rule governing sidecar filename truncation — published figures disagree, and nothing official documents it — nor whether Google intends the .supplemental-metadata naming to be stable. Anyone scripting against it is scripting against undocumented behaviour that has already changed once.

Sources

Procedures and limits verified September 21, 2026 against Google and Apple documentation and subject to change. GadgetGlow Bytes does not test hardware or receive products from manufacturers for coverage; all hands-on findings above are attributed to the projects and documentation that reported them.

Search This Blog

GADGETGLOW BYTES