Google Takeout Videos Have the Wrong Date. Here Is Why
Why videos from a Google Takeout export show the download date, where a video's date actually lives, MOV vs MP4, and how to set it right.
You fixed your photos and they look right. The videos did not budge. Every MP4 and MOV still says it was created on the day you unzipped, and they sit in a clump at the end of your timeline.
Videos keep their date in a different place from photos, and most photo-fixing steps skip it.
Videos do not have EXIF
EXIF is a photo format. JPEG, HEIC, PNG and TIFF carry it. Video files do not. An MP4 or MOV stores its date inside the container, in a header called the movie atom, in fields named CreateDate and ModifyDate. There are also per-track copies, TrackCreateDate and MediaCreateDate. Photo apps read CreateDate, and some check the track fields when it is empty.
Any tool or command that writes DateTimeOriginal does nothing for a video. exiftool will warn that the tag is not supported and move on. Scripts written for photos often skip the .mp4 extension entirely, so the user sees a clean run and wrong videos.
Where Takeout puts the video's date
Every video in a Takeout has a .json sidecar just like a photo, with photoTakenTime holding the real date. That is the source of truth. The video file itself may or may not have a container date. Phone cameras write one, so a video straight from a phone is often fine. Google's re-wrapping of some files, and uploads from other sources, can leave the container date empty or set to the upload time.
When the container date is missing, apps fall back to the file's modified date, which is the unzip time. That is the clump you see.
Live Photo clips are a special case. The short MP4 beside a still often has no sidecar at all. It should take its date from the still, which is covered in Takeout Live Photos as MP4 and MOV pairs.
MOV versus MP4
MOV is Apple's container, MP4 is the standard one. They are close relatives and store the date in the same kind of field. iPhone videos are MOV; Android videos are MP4; Google often re-wraps MOV to MP4 in Takeout. The date fix is identical for both.
Time zone is the difference to watch. The MP4 standard says container dates are UTC, and most players convert them to local time on display. Some cameras write local time anyway. exiftool has a switch, -api QuickTimeUTC, that tells it to treat the field as UTC, which is the correct behavior for anything a phone produced. Without it, a video can display several hours off.
Fixing video dates by hand
With exiftool, from the Google Photos folder:
exiftool -r -d %s -api QuickTimeUTC -tagsfromfile "%d/%F.supplemental-metadata.json" \
"-CreateDate<PhotoTakenTimeTimestamp" "-ModifyDate<PhotoTakenTimeTimestamp" \
"-TrackCreateDate<PhotoTakenTimeTimestamp" "-TrackModifyDate<PhotoTakenTimeTimestamp" \
"-MediaCreateDate<PhotoTakenTimeTimestamp" "-MediaModifyDate<PhotoTakenTimeTimestamp" \
"-FileModifyDate<PhotoTakenTimeTimestamp" \
-ext mp4 -ext mov -ext 3gp -overwrite_original .Run it again with "%d/%F.json" for older exports. exiftool rewrites the container header, not the video data, so the operation is fast and lossless. Sidecar names that are truncated or carry a (1) counter need the same extra handling as photos; see the exiftool guide.
Old formats are the exception. AVI, WMV, 3GP and MPEG files from cameras of the 2000s have limited or no date fields, and many players cannot read what is there. For those the file modified date is the only date most software sees. Convert them to MP4 and then set the container date, or set the file date and move on.
Fixing them with the app
Takeout JSON Metadata Fixer handles videos in the same run as photos, on macOS, Windows and Linux.
It reads each video's sidecar and writes photoTakenTime into the container date fields, treating them as UTC so players show the correct local time. The file modified date is set to match, so file managers agree. A video with no sidecar keeps the creation time stored in its own container, if it has one, and only falls back to the file date when nothing else exists.
Old videos can be converted to MP4 on the way through. H.264 in a MOV or AVI wrapper is re-wrapped losslessly, so the quality is untouched and the conversion takes seconds. Older codecs are re-encoded to H.264. The correct date is written into the new file. This needs ffmpeg installed; the app tells you if it is missing and copies videos through unchanged. See converting old AVI and MOV videos to MP4.
Videos are renamed and sorted with the same templates as photos, so a clip from a birthday lands in the same month folder as the photos from it. The first 500 items are free.
Checking a video's date
exiftool -time:all IMG_5540.MP4 lists every date field in the file. Look for Create Date and Media Create Date. If both say 1904 or are blank, the container has no date. On a Mac, Get Info shows "Content Created" for videos with a container date. On Windows, the Properties, Details tab shows "Media created".
Frequently asked questions
Why do photos from the same day sort before the video?
Time zone, usually. The photo's EXIF is in local time with no zone. The video's container date is UTC and the player converts it. A few hours of drift between them is common and mostly harmless.
exiftool says "Warning: [minor] The ExtractEmbedded option may find more tags". Is that a problem?
No. It is telling you there is more metadata in the video stream than it read by default. The date fields are in the header and were handled.
Do videos count as photos in the free tier?
Yes, each video is one item.
Will re-wrapping to MP4 keep the date?
Yes. The container date is copied across, and the app writes the sidecar date into the new file. Re-encoding old codecs also keeps it. Only the video stream changes.