Home · Updated September 2026
They are the dates. Google took the capture date, the GPS position and the caption out of every photo and put them in a separate file next to it. That is why your export looks like it was all shot today.
This page answers the questions people actually ask about Google Photos Takeout exports. It is built from 346 public posts we collected and read, so the order below roughly matches how often each problem comes up. The short version: do not delete the .json files, and merge them into your photos before you import anything anywhere.
They are sidecar files. Each one holds the metadata for the photo sitting next to it: the real capture date, the GPS position, the description you typed, the album it belonged to, and whether you favourited it.
Takeout/Google Photos/Portugal 2019/ IMG_0001.jpg IMG_0001.jpg.supplemental-metadata.json <- the date lives in here IMG_0002.jpg IMG_0002.jpg.supplemental-metadata.json
Inside, the part that matters looks like this:
{
"title": "IMG_0001.jpg",
"description": "Rooftops in the old town",
"photoTakenTime": { "timestamp": "1562241600" },
"geoData": { "latitude": 38.7223, "longitude": -9.1393 }
}
That timestamp is the real moment the photo was taken, in seconds
since 1970. It is not in the photo. It is only here.
Because the photo no longer carries a date of its own, so your computer shows the only date it has: the day the file was created on your disk, which is the day you unzipped the export.
Photos normally store their capture time in an EXIF tag called
DateTimeOriginal, written by the camera. Google's export process
frequently leaves that tag empty or stale, having moved the authoritative value
into the sidecar. Your Mac or PC has nothing to fall back on except the file
timestamp.
This is also why the problem looks worse the more you touch the files. Copying an export to another drive rewrites the file dates again.
Not yet. This is the single most expensive mistake people make with a Takeout export.
For a large share of your photos, that sidecar is the only surviving copy of the capture date, the GPS position and the caption. Screenshots, saved images, WhatsApp photos, scans, and anything whose date you corrected by hand inside Google Photos have nothing else. Delete the .json files and that information is gone for good — Google's export is a one-way door.
The right order is: merge first, verify, then delete the sidecars.
Every method does the same three things: find the sidecar that belongs to each photo, read the timestamp and coordinates, and write them into the photo's EXIF. They differ only in how much work you do.
| Option | Cost | Good when | Watch out for |
|---|---|---|---|
| exiftool + a script | Free | You are comfortable in a terminal and want total control | You have to handle Google's several sidecar naming schemes yourself; a wrong flag rewrites thousands of files |
| GPTH (Google Photos Takeout Helper) | Free | Purpose-built for exactly this; command line | Command line only |
| immich-go | Free | Your destination is an Immich server | Tied to Immich |
| A Mac app | Free tier, paid for large libraries | You want a window, a preview and a report instead of a terminal | macOS only |
Whichever you pick, insist on two things. First, work on a copy — never let a tool rewrite your only export in place until you have seen the result. Second, demand a per-file report. Silent failure is the common complaint about this whole category of tool: it says "done", and you find out months later that a few thousand photos never got their date.
We make Takeout JSON Metadata Fixer, a Mac app that does this without a terminal. It reads every sidecar naming scheme Google has used, writes the date, time zone, GPS and caption back into each photo, and files them into folders by year and place. It reports each file it could not match rather than claiming success. The first 500 photos are free so you can check the result before paying.
macOS only. The free command line tools above are genuinely good — if you are happy in a terminal, use them.
Because photo apps sort by capture date, and every photo now carries the same one. Twenty years of pictures collapse into a single day, in whatever order the files happened to be written.
Sorting fixes itself the moment the real dates are back in the files. You do not need to rename anything or arrange folders by hand — that is treating the symptom.
Nine times out of ten the metadata is there and the sidecar simply is not being
matched to its photo. Google has changed the naming scheme repeatedly and never
documented it. A tool that only looks for photo.jpg.json will miss
most of a modern export.
The variants you have to handle:
IMG_1.jpg.json — the old scheme, pre-2024IMG_1.jpg.supplemental-metadata.json — the current oneIMG_1.json and IMG_1.supplemental-metadata.json — the extension droppedIMG_1.jpg.supplemental-metadata(1).json — for a duplicate name, the counter moves off the photo and onto the sidecarPXL_20230815_142536789.jpg.supplemental-m.json — Google truncates the whole sidecar name at 46 characters, so the suffix is cut mid-wordIf a tool reports that most of your library has no metadata, suspect the matching before you believe the export is broken.
Fix the metadata before you import. Not after.
Apple Photos reads the EXIF DateTimeOriginal tag inside each file
and ignores .json sidecars entirely. Drag a raw Takeout export into Photos and
you get your entire library stamped with today's date, scattered through the
wrong years, with no location — and correcting it inside Photos afterwards means
editing them one at a time.
The order that works:
One extra thing worth doing first: convert HEIC to JPG only if you actually need to. Apple Photos handles HEIC natively, so converting costs quality for nothing unless you are also sending the library to Windows or an old TV.
Same rule: repair before you import, because these servers index on the EXIF date at import time and re-indexing later is painful.
If your destination is Immich specifically, immich-go reads Takeout exports natively and is the path of least resistance. For Synology Photos, Nextcloud, Plex or plain folders on a NAS, merge the metadata first with any tool you like, then copy the finished folders across.
They came out as folders, and this surprises people twice.
First, each album is a folder of its own, alongside year folders like
Photos from 2019. Second, a photo that was in three albums is
exported three times, once in each album folder, plus once in the year
folder. Nothing is missing; there is simply more of it than you expect. Album
membership is also recorded inside the .json files, so a tool can rebuild the
structure if you would rather organise by date.
Same reason as the dates: it is in the sidecar, under geoData, not
in the photo. Two details catch people out.
Google writes 0.0, 0.0 when it has no location — a real place in
the Atlantic Ocean, not a blank. A naive merge writes that into thousands of
photos and puts your whole library off the coast of Africa. Anything sensible
treats 0,0 as "unknown".
And some exports carry geoDataExif as well as geoData.
When they disagree, the plain geoData is the one Google Photos was
showing you.
Three separate causes, and they stack:
Deduplicate by file content, not by filename. The same image frequently arrives under two different names, and two genuinely different photos can share one. A checksum settles it; a filename does not.
If you cropped, rotated or filtered a photo inside Google Photos, the export
contains both versions: the untouched original and a second file ending in
-edited.
Google does not mark which one you were actually looking at in the app — and it was almost certainly the edited one. Decide deliberately which you want to keep before you delete anything, because for many people the edited version is the photo they remember.
They were split in two: a still image and a separate short video, usually
.MOV, sitting beside it with the same base name.
Apple Photos will rejoin the pair on import only if both halves still share that base name. So if you rename your photos — which most organising tools do — rename both halves identically, or the pairing is silently lost. Nothing warns you. The photo simply stops moving, and you find out much later.
Takeout/
Google Photos/
Photos from 2019/ <- everything from that year
IMG_0001.jpg
IMG_0001.jpg.supplemental-metadata.json
Portugal 2019/ <- an album, with copies of the same photos
Screenshots/ <- Google's own screenshots album
user-generated-memory-titles.json
print-subscriptions.json <- housekeeping, not photos
If your export is large, Google gives you several zip files named
takeout-…-001.zip, -002.zip and so on. A single photo's
image and its .json can land in different zip files, so always extract
every part into one folder before you start. Half an export produces exactly the
"missing metadata" symptom above.
Sometimes. Google's own transfer service can copy your library directly to some services without you touching a zip file, and Apple offers a Google Photos to iCloud transfer that avoids Takeout entirely. Where those cover your case they are less work.
They are not a universal answer: they support a limited set of destinations, they can take days, and they do not help if you want your photos as ordinary folders on your own drive. If you want files you control, Takeout is still the way out — you just have to repair what it gives you.