EXIF & Metadata
Google Takeout Metadata Fixer
Merge the JSON sidecars from a Google Photos export back into your photos and videos — date taken, GPS location and captions written into the files, right in your browser. Drop the Takeout ZIPs; nothing is uploaded, nothing is installed.
Your export is read and rewritten entirely on this device — no photo, JSON or filename ever leaves it.
To fix Google Takeout photos, drop the export ZIPs above — each JSON sidecar is matched to its photo and the date taken, GPS location and caption are written into the file, entirely in your browser. Nothing is uploaded, nothing installed, no photo limit. Import the fixed ZIP into Apple Photos, Immich or Lightroom and the timeline sorts itself.
Honest limits
- JPG, PNG, WebP, HEIC/AVIF and MP4/MOV are rewritten losslessly; GIF, RAW and the rest keep their bytes and get the date as a file timestamp.
- HEIC and video dates are patched in place, so a file with no EXIF block or no date slot at all is passed through unchanged — and reported.
- Chrome and Edge stream the result into a folder you pick; Safari and Firefox build the ZIP in memory — feed them one Takeout part at a time.
- Live Photo pairs keep both halves and the same date, but the .MP4 half only gets a QuickTime date — videos have no standard GPS slot.
Need more than a browser can do? Desktop browsers go further than phones — and Media Moana converts at scale on hosted infrastructure.
How it works
Export from Google Takeout
At takeout.google.com choose only Google Photos, the .zip format and any part size — 50 GB parts are fine, the tool never loads a whole archive.
Drop the ZIPs here
All parts at once, or the already-unzipped folder. Pick the time zone the photos were taken in; the sidecars are matched before anything is written.
Save the fixed export
Chrome and Edge stream it into a folder you choose; other browsers download a ZIP. Import into Apple Photos, Immich or Lightroom — dates and places just work.
Frequently asked questions
Why do my Google Takeout photos have the wrong dates and no location?
Google Photos keeps the date, location, caption and album of every picture in its own database, not only in the file. When you export with Takeout, that information comes out as a separate .json 'sidecar' next to each photo — IMG_1234.jpg plus IMG_1234.jpg.supplemental-metadata.json — while many of the files themselves carry no EXIF at all (screenshots, WhatsApp images, PNGs, anything Google re-rendered). Import those into Apple Photos, Immich or a plain folder and everything sorts by the download date. This tool reads each sidecar and writes its data back into the photo, so the timeline is right again.
What exactly gets written into each file?
Three things, when the sidecar has them: the moment the photo was taken (written to DateTimeOriginal, DateTimeDigitized and DateTime, plus the EXIF 2.31 OffsetTime tags so the time zone is unambiguous), the GPS latitude, longitude and altitude, and the caption you typed in Google Photos as the image description. JPG, PNG and WebP get a rebuilt EXIF block with every other tag preserved; HEIC, AVIF and MP4/MOV are patched in place — the existing date and location fields are overwritten byte for byte, so the file size never changes and pixels are never touched.
Which files can it fix, and what happens to the rest?
Dates and locations go into JPG, PNG, WebP, HEIC and AVIF photos; MP4 and MOV videos get the capture date in their QuickTime header (creation time), which is what Apple Photos, Immich and Plex read. GIF, camera RAW and anything else are passed through unchanged — but every file in the output ZIP also carries the capture date as its file timestamp, which is the fallback most photo apps use when there is no EXIF. Nothing is ever dropped silently: the summary lists each file whose date could not be written and every file that had no sidecar.
How do I move Google Photos to iCloud or Apple Photos with the right dates?
Export with Google Takeout (Google Photos only, .zip format), drop the ZIPs here, and import the fixed ZIP's contents into the Photos app on your Mac or iPhone — it reads the EXIF date and GPS and files everything under the day and place it was actually taken, then syncs to iCloud. Because the tool also stamps Live Photo video halves with the still's date, HEIC + MP4 pairs stay together in the timeline. Skip duplicates is on by default, so a picture that Google put in three album folders arrives once.
Does it work for Immich, Synology Photos, Nextcloud or just a folder on disk?
Yes — anything that reads EXIF works, because the metadata is inside the files afterwards rather than in a database. Immich and Synology Photos read DateTimeOriginal and GPS on import and place photos on the map; Lightroom, digiKam and Windows Explorer sort by the same tags. If you only want an orderly folder, the fixed ZIP keeps Google's folder structure (Photos from 2019, album names) minus the JSON clutter, with each file's modified time set to its capture date.
My export came as several ZIP files. Do I have to combine them first?
No. Drop every part at once. Takeout splits big libraries into 2 GB, 10 GB or 50 GB archives and does not care whether a photo and its JSON sidecar land in the same part — they frequently don't. The tool indexes all the sidecars across every archive before it touches a single photo, so a picture in part 3 still finds its metadata in part 1. Only the archive's index is read up front; each photo is then read, fixed and written one at a time, which is how multi-gigabyte exports fit in a browser tab.
What about duplicates and the '-edited' copies?
Google Takeout puts a photo in its year folder and again in every album it belongs to, and edited pictures come out twice — the original plus a '-edited' render that has no sidecar of its own. Both are handled: identical files are detected by content, not name, and kept once (the year-folder copy wins), and the edited copy inherits the original's date and location. A checkbox lets you drop the edited versions entirely if you only want originals. Files Google renamed with '(1)' or truncated to 46 characters are matched using the same rules Takeout used to mangle them.
Which time zone will the photos get?
Google records the capture moment in UTC; EXIF stores a wall-clock time with an optional offset. The tool converts using the time zone you choose (it defaults to your browser's) and writes the offset alongside, so the exact instant is preserved either way — a photo taken at 14:00 in Tokyo shows 14:00 with +09:00, and an app that understands offsets never shifts it. If your photos already have a date in the file, the default 'fill only what's missing' mode leaves it alone; switch to 'overwrite' when you corrected dates inside Google Photos and want those to win.
How is this different from Metadata Fixer or Google Photos Takeout Helper?
Metadata Fixer is a $39 desktop app (a free trial covers 100 photos) that you download and install on Mac, Windows or Linux; Google Photos Takeout Helper and similar projects are free command-line tools you run in a terminal. Both are solid and can do things a browser can't, such as setting file timestamps on your disk directly. This page sits in the gap between them: nothing to install, nothing to pay, no terminal — and, because everything runs in your browser with WebAssembly, no family photos are uploaded to anyone's server. For a one-off migration of a personal library it's the shortest path; for scripting a server, a CLI still fits better.
Is this safe? Do my photos get uploaded?
No upload happens — ever. Fixing your export runs entirely inside your browser using WebAssembly. Your files never leave your device, nothing is stored on any server, and the tool even keeps working if you go offline after the page loads. That's also why there are no file size limits, no queues and no sign-up.
Is there a file size or quantity limit?
There is no hard limit. Server-based converters cap uploads because your files consume their bandwidth and CPU; here rewriting your export happens on your machine, so the only practical limit is your device's memory. Desktop browsers comfortably handle very large files and big batches.