Why exported Snapchat Memories lose their dates, and how to fix the EXIF

Snapchat's My Data export gives you the photos and videos. It does not give photo apps a capture date they can sort on. The files arrive, the years collapse onto the day you unzipped the ZIP, and the map stays empty even when Snapchat knew where the Snap was taken.

This is a metadata mismatch, not a failed download. The capture time is in the export. It is just not in the field Google Photos and Apple Photos read.

What the ZIP actually contains

Request the export from accounts.snapchat.com: My Data, turn on Export your Memories, then submit. Snap's help page says they aim to deliver data within 7 days, and that large downloads can take longer. Download every part of the ZIP. A single part, or the HTML index without the media files, is not the whole library.

Inside a current export you should find media files plus memories_history.json. The JSON row for a Snap carries the capture time as a UTC timestamp, in a shape like 2017-04-03 22:11:04 UTC. Newer exports also split a memory into a camera file whose name ends in -main and a transparent -overlay.png for the caption or sticker. Older exports use a memories/ folder and a date prefix on the filename.

None of those are EXIF. Unzipping also stamps the filesystem "modified" time as today on macOS and Windows. Finder can look correct if you sort by filename and wrong if you sort by Date Modified. Photo libraries ignore both the filename and that filesystem time.

Which fields photo apps actually read

For a JPEG, Google Photos and Apple Photos sort on EXIF:

• DateTimeOriginal
• CreateDate (also called DateTimeDigitized in some tools)
• GPSLatitude and GPSLongitude, if you want the map

For an MP4, they read the QuickTime creation time stored in the mvhd, tkhd, and mdhd atoms. A date that exists only in a sidecar JSON never reaches those atoms.

So the fix is a copy, not a guess. Read the UTC time from the JSON row that matches the file. Write that same instant into the photo or video. If the JSON location is missing or N/A, leave GPS empty. Do not invent coordinates.

EXIF wants YYYY:MM:DD HH:MM:SS with colons in the date. The JSON value 2017-04-03 22:11:04 UTC becomes 2017:04:03 22:11:04. Keep the clock time in UTC when you write QuickTime fields, then check the result in Photos. A one-hour shift usually means the app displayed local time, not that the day was wrong.

Check one file before you batch

Install ExifTool if you want to do this by hand. On one JPEG:

exiftool -DateTimeOriginal -CreateDate -GPSLatitude -GPSLongitude photo.jpg

If DateTimeOriginal is missing, or it shows the day you downloaded the ZIP, the file still has the export stamp. After you copy the JSON time:

exiftool -DateTimeOriginal="2017:04:03 22:11:04" \
  -CreateDate="2017:04:03 22:11:04" \
  -ModifyDate="2017:04:03 22:11:04" \
  photo.jpg

Replace the timestamp with the value from that file's JSON row. ExifTool keeps the original bytes beside the file as photo.jpg_original unless you pass -overwrite_original.

For a video, tell ExifTool the value is UTC:

exiftool -api QuickTimeUTC=1 \
  -QuickTime:CreateDate="2017:04:03 22:11:04" \
  -QuickTime:ModifyDate="2017:04:03 22:11:04" \
  clip.mp4

Run the read command again. You want the year and day from the JSON, not today. Then import that one file into Google Photos or Apple Photos and confirm the library year before you touch the rest of the ZIP.

GPS is the same idea. The JSON line looks like Latitude, Longitude: 40.7128, -74.0060. West and south need the ref tags:

exiftool -GPSLatitude=40.7128 -GPSLatitudeRef=N \
  -GPSLongitude=74.0060 -GPSLongitudeRef=W \
  photo.jpg

Use the signs from your own row. A positive longitude is east (GPSLongitudeRef=E). If the row has no numbers, skip this. Filename-only dates do not contain a location.

Why a folder of files still goes wrong

Hand-editing a few dozen photos is realistic. A full Memories export is not, for three reasons that show up after the dates are fixed.

The overlay PNG is transparent. Photos apps paint transparency black, so importing -overlay.png alone produces a black card. The picture is the -main file. The caption lives in the overlay. You either composite them or keep the PNGs out of the library.

Long recordings are often several short MP4s that share an id. Dating each part puts them next to each other. Joining them into one clip is a separate step, and it still needs the same QuickTime dates on the output or the merged file falls back to today.

The JSON is usually in the first ZIP part. If you only downloaded a later part, you can have media with no timestamps to copy. Match the file name or id to a row before you write anything.

Doing that match, the EXIF write, the GPS write, and the overlay composite for every file is the tedious part. I use a browser tool that reads the official ZIP locally and writes DateTimeOriginal plus QuickTime creation time from memories_history.json, without uploading the photos: fix the dates on a Snapchat Memories export. The manual ExifTool path above is the same correction if you would rather script it yourself. A longer walkthrough of the field mismatch is on why exported Snapchat Memories show the wrong date.

After the files are dated

Import the corrected folder, not the raw unzip. In Google Photos, new uploads pick up DateTimeOriginal on the way in. Changing a file that is already in the library often means deleting that copy and uploading the corrected one. Apple Photos behaves the same way: the date is captured at import.

Do not rely on "Adjust Date and Time" in the Photos app for a whole year of Snaps. That shifts a selection by one offset. Memories span many years, each with its own timestamp in the JSON.

Two limits are worth knowing so you do not blame the EXIF write for them. Snapchat's export only includes Memories still on the account. A Snap you never saved, or one Snapchat has already removed, will not be in the ZIP. And from January 2027, Snap's help center says Memories older than a year that sit outside your oldest 5GB can be archived as thumbnails. Download those before you need a full-resolution file. Archiving is separate from the date bug: a file you already exported can still show today's date until the EXIF is written.

When you are done, spot-check the oldest year, a video, and one photo that had a location. If those three land on the right day, the copy from JSON to EXIF worked.