Takeout Photo Date Fixer for Google Photos Exports

About the Takeout Photo Date Fixer for Google Photos Exports

A Google Takeout download of Google Photos is a set of ZIP archives in which the dates, places and captions sit in separate JSON files, one beside each photo. Google’s own help says a downloaded file keeps “the original timestamp preserved in the metadata embedded within the files”, and that information which “isn’t from the original file” goes to a secondary JSON file (Google Account Help). So camera photos usually need nothing — while screenshots, pictures saved from the web or a chat, scans and many videos arrive with no date inside them at all, and anything whose date you corrected in Google Photos carries the old one.

This page opens the archives — or the folder you unpacked them into — on your own device, pairs every photo and video with its JSON file through the naming shapes exports really use, and says before anything is written how many files need a change. It then writes the capture date (with the UTC offset beside it), the position and the caption into the formats that can hold them, drops files whose bytes are identical, and arranges a copy by year and month. Your export is read, never changed, and nothing leaves the device.

Common uses

• Moving a library out of Google Photos to another app, a computer or a drive, and keeping the dates.
• Getting screenshots, saved pictures and chat images to sort by the day they were taken.
• Keeping the places and captions you added in Google Photos inside the files themselves.
• Thinning out an export: exact duplicates across the ZIP parts, and files with no date at all, are listed.

What the JSON files hold, and what is used

• photoTakenTime.timestamp — the moment the photo was taken, in seconds of UTC. This is the only field used as the capture date.
• creationTime — when the item reached Google Photos. It is listed in the CSV report but never written as a capture date: for a scan or a forwarded picture it is the upload day, not the day in the picture.
• geoData and geoDataExif — the position Google Photos holds, and the one the uploaded file carried. geoData is used first (it is what you see in Google Photos), with geoDataExif as the fallback; a pair of exact zeros means “no position” and is ignored.
• description — the caption typed in Google Photos; it goes into the file’s ImageDescription. A description the file already has is kept, except the text a camera puts into every photo on its own (“OLYMPUS DIGITAL CAMERA”, “SONY DSC”), which your caption replaces.
• title — the file’s original name. It is what matches a photo whose JSON name an export shortened.
• An album folder’s own metadata.json, and an export’s lists such as print-subscriptions.json, belong to no photo and are counted apart.

Which JSON names are matched

Google has changed the way sidecars are named more than once, and long names are cut short. Each row of the report says which of these matched, so you can check it:

• IMG_1.jpg ← IMG_1.jpg.json — the plain form.
• IMG_1.jpg ← IMG_1.jpg.supplemental-metadata.json, and every shortened form of it down to IMG_1.jpg.s.json.
• IMG_1(1).jpg ← IMG_1.jpg(1).json — a repeated name keeps its “(1)” after the extension in the JSON’s name.
• IMG_1-edited.jpg → the original’s JSON. The suffixes reported from exports in several languages are known (-bearbeitet, -modifié, -ha editado, -編集済み and more), and you can add your own language’s.
• A Live Photo: IMG_1.MP4 beside IMG_1.HEIC uses the picture’s JSON when it has none of its own.
• By the title inside the JSON, for names an export cut short.
• A shortened name that fits only one file in its folder. If it fits two, neither is used — a wrong date is worse than none.

Matching never crosses a folder: a JSON in one album is never used for a photo in another, even when the names agree.

What is written into each format

• JPEG — DateTimeOriginal, DateTimeDigitized and DateTime, each with OffsetTimeOriginal, OffsetTimeDigitized and OffsetTime (the offset tags of Exif 2.31), the GPS directory, and ImageDescription for the caption. New tags are added at the end of the Exif block and nothing already there is moved, so thumbnails and a camera’s own maker notes keep working. Fields the file already has in the right form are left alone. (CIPA DC-008, Exif 2.32)
• PNG — the same Exif block in an eXIf chunk, written after IHDR and before the first IDAT, where the PNG specification puts it (one found after the picture data is moved there). The picture data is untouched. Screenshots are usually PNG, and they are the files that most often have no date.
• MP4, M4V, MOV and 3GP — the creation time in the movie, track and media headers (mvhd, tkhd, mdhd), in seconds since 1904-01-01 UTC, and the modification time beside it where it was not set (ISO/IEC 14496-12 and the QuickTime File Format). The fields are the same size before and after, so the rest of a video — gigabytes of it — is copied exactly, whatever its size.
• HEIC, AVIF, RAW, GIF, BMP, WebP and TIFF — copied without a change. Their recovered dates are in the report, and the copy’s folders carry the date, so a later import can still sort them. Writing their metadata is not offered until it is tested on real files.

The bytes decide, not the name: a PNG saved with a .jpg name is written as the PNG it is, and a file whose metadata cannot be written (a damaged Exif block, a .jpg that holds something else) still goes into the copy, unchanged, with the reason in the report.

Dates inside a file, and dates on the disk

There are two different dates. The one inside the file (Exif, or a video’s header) is what photo apps read when they import, and that is the one this page repairs. Only a date taken counts as one (DateTimeOriginal, or DateTimeDigitized): a “date modified” alone is the day an app last saved the file, so such a file is treated as having no date, and the report shows the date it had. The one on the disk — “date modified” in a file manager — is set by your computer when the file is written, and no web page can change it: Google’s help says the same, that “your operating system can assign a new timestamp to the file itself”.

That matters for the two ways of taking the copy:

• ZIP archives: each file is stored with its capture moment as the archive’s own date for it — in local time, which every unzip tool reads, and as a UTC timestamp, which tools such as 7-Zip and Info-ZIP’s unzip use when it is there — and unzip tools apply that date when they unpack. So a sort by file date is right as well.
• A folder on this device (Chrome and Edge on a computer): the files appear at once, with no unpacking, but they carry today’s date on the disk. The folder names (2019/2019-07/) and the dates inside the files still sort correctly, and an import into a photo app reads the Exif date, not the disk date. Choose an empty folder outside the export: a file that is already there is never written over, and the export’s own folder is refused.

Before you move a whole library

Try one photo and one video first: fix a handful of files, open them in the app you are moving to, and check what it shows. Apps differ in which tag they read — most read the Exif date for photos, while some read a video’s date from a different place than the headers written here.

Keep the original export until you are satisfied. Nothing here changes it, and a second run costs only time.

Other ways to do this job exist, including open-source command-line helpers; this page needs nothing installed and shows you the report before you decide. Google, Google Photos and Google Takeout are trademarks of Google LLC; MySmartCoPilot is not affiliated with Google, Apple or any other company named on this page.

Limitations

• ZIP archives only. A TGZ archive cannot be read here: ask Takeout for .zip, or unpack the TGZ on your computer and choose the folder.
• A browser cannot set a file’s own date on the disk. The ZIP route stores the capture date with each file so most unzip tools apply it; the folder route cannot.
• HEIC, AVIF, RAW, TIFF, GIF, BMP and WebP files are copied unchanged, with their recovered dates in the report and in the folder names; videos other than MP4, M4V, MOV and 3GP are copied unchanged too.
• A video gets the creation time in its mvhd, tkhd and mdhd headers. Some apps read a separate creation-date tag instead (Apple’s QuickTime files carry one), which is neither added nor changed here, because that needs the file rebuilt; the report says when a video whose date is replaced carries one, so check one video before moving a library.
• Camera photos almost always carry their date already, so a large export may need very few changes. The scan says how many, and nothing is written into a file that is already right.
• Up to 25,000 photos and videos in one run (their JSON files are not counted); the page says how many were left out, and choosing fewer ZIP parts at a time covers the rest. JPEG and PNG files above 80 MB are copied without a metadata change, and files above 2 GB are not compared for duplicates.
• Reading tens of gigabytes takes a long time, and the page must stay open while it works. Each ZIP is built on this device, so several downloads may follow one another and the browser may ask to allow them.
• A file whose JSON holds no date taken, and which has no date inside and none in its name, is listed as “no date found” and, when the copy is arranged by date, goes to an “Unknown date” folder: nothing is invented.
• Files that are not photos or videos (the export’s own HTML page, unknown file types) are counted in the report and left out of the copy.

Privacy

Everything runs in this browser: the archives are read with the File API, the JSON files are parsed here, the metadata is written here, and the copies are built here. No file, name, caption or position is ever uploaded, and your export itself is only read.