Why do all my Snapchat photos show today's date?

Because Snapchat's export writes no date into the files themselves. Your gallery falls back to the file's creation or download date, so everything looks like it happened the day you exported. The real capture date is stored only in memories_history.json, in a field your photo app never reads.

Which date field does MemoriesExport write?

It writes the original capture time to the standard EXIF DateTimeOriginal (and CreateDate) for photos, and the QuickTime creation-date atoms for videos — the exact fields Apple Photos and Google Photos read to place a memory on your timeline.

Does this change the photo itself?

The date fix touches metadata only — it writes tags into the file with exiftool and never re-encodes or degrades the image, so the pixels are untouched. (Overlays are the one exception: if you keep captions and stickers, those are composited back onto the photo on purpose.)

Will Apple Photos and Google Photos then sort everything right?

Yes, at the day level. Once each file carries its own real capture date, Apple Photos and Google Photos rebuild the chronology on import — a 2019 memory lands in 2019, a 2023 one in 2023. See our note on why Google Photos shows the wrong date for the full mechanism.

What about videos — do their dates get fixed too?

Yes. Videos lose their dates the same way photos do, and MemoriesExport writes the QuickTime creation-date atom so they sort alongside your photos. It also writes the QuickTime Keys:GPSCoordinates atom Apple Photos specifically needs to pin a clip on the map — the atom most other tools can't write.

Will the times be in the right timezone?

Snapchat records each memory's capture time, and MemoriesExport applies it so your memories sort in the correct order rather than collapsing onto one day. One honest limit: for several memories captured on the same day, Snapchat's export gives no per-item join key, so the exact minute-by-minute order within that day can't always be reconstructed — the day is right, the second-level order within it may not be.

My export shows the year 2052 (or some other far-future date). Same fix?

Yes. A wildly wrong year is the same root cause — a garbage fallback date because the file has no real capture date inside it. Writing the true date from the JSON replaces it.

Fix dates

Snapchat timestamp wrong? Fix the dates on your export

After you export Snapchat Memories, every photo and video shows the date you downloaded it — not when you actually took it. Here's why, and how to write the real capture date back into the files so your library sorts itself out.

Why the dates are wrong

Photos and videos store their capture time in their own metadata (EXIF DateTimeOriginal for images, QuickTime atoms for video). Snapchat's export leaves those fields empty and keeps the real date in a separate memories_history.json file instead. So when you import the files, your photo app has nothing to read and stamps them all with the import date — burying years of memories on a single day. It's the same reason your Memories come out of order and, in the worst cases, why an export can show a nonsense year like 2052.

How MemoriesExport restores the dates — step by step

MemoriesExport reads the capture time for each memory from the export's JSON and writes it back into the file's own metadata. You export and download from Snapchat yourself — it's the after step, and it never fetches anything from Snapchat's servers. Here's the whole flow:

Export and download your Memories from Snapchat. Request your data from Snapchat with Memories included, then download every zip part. Large libraries arrive as several mydata~*.zip files — grab the full set, because the memories_history.json that holds the real dates lives in only one of them.
Hand the export to MemoriesExport. Open the export you already downloaded in the browser, or drop it into the Mac/Windows desktop app. MemoriesExport never fetches anything from Snapchat — it works only on the files you give it.
It reads the real capture date for every memory. MemoriesExport parses memories_history.json and matches each entry to its photo or video, recovering the original capture time Snapchat recorded when the memory was taken.
It writes that date into each file's own metadata. For photos it writes EXIF DateTimeOriginal and CreateDate; for videos it writes the QuickTime creation-date atoms. The same pass restores GPS and merges overlays, so the file carries everything a photo app looks for.
Download the corrected zip and import that. You get a download-ready zip with the dates baked into the files. Import the corrected copies — not the raw export — and your gallery rebuilds the timeline on its own.

It does the same for GPS location and overlays in the same pass — see how it works for the full mechanics.

How to verify the date is actually in the file

You can confirm the fix worked before you import anything. The trick is to check the capture date inside the file, not the filesystem's created/modified date — those are different things, and only the first one is what photo apps sort by.

On a Mac: open the photo in Preview → Tools → Show Inspector and look at the EXIF tab — DateTimeOriginal should now read the real capture date. (Finder's Get Info only shows the file's Created/Modified dates, so it may still say the download date even after a successful fix — don't use it to judge the result.) On the command line, exiftool -DateTimeOriginal yourphoto.jpg prints it directly. Prefer a GUI? Our guide to fixing Snapchat EXIF on a Mac walks through it.
On Windows: right-click the file → Properties → Details and read the Date taken field. That one reads the EXIF date, so it reflects the fix correctly.
The real test: import the corrected files into Apple Photos or Google Photos and watch them land on the right day. If they sort into the correct years, the dates are in the files.

Fix my Snapchat dates →

Frequently asked questions

Why do all my Snapchat photos show today's date?: Because Snapchat's export writes no date into the files themselves. Your gallery falls back to the file's creation or download date, so everything looks like it happened the day you exported. The real capture date is stored only in memories_history.json, in a field your photo app never reads.
Which date field does MemoriesExport write?: It writes the original capture time to the standard EXIF DateTimeOriginal (and CreateDate) for photos, and the QuickTime creation-date atoms for videos — the exact fields Apple Photos and Google Photos read to place a memory on your timeline.
Does this change the photo itself?: The date fix touches metadata only — it writes tags into the file with exiftool and never re-encodes or degrades the image, so the pixels are untouched. (Overlays are the one exception: if you keep captions and stickers, those are composited back onto the photo on purpose.)
Will Apple Photos and Google Photos then sort everything right?: Yes, at the day level. Once each file carries its own real capture date, Apple Photos and Google Photos rebuild the chronology on import — a 2019 memory lands in 2019, a 2023 one in 2023. See our note on why Google Photos shows the wrong date for the full mechanism.
What about videos — do their dates get fixed too?: Yes. Videos lose their dates the same way photos do, and MemoriesExport writes the QuickTime creation-date atom so they sort alongside your photos. It also writes the QuickTime Keys:GPSCoordinates atom Apple Photos specifically needs to pin a clip on the map — the atom most other tools can't write.
Will the times be in the right timezone?: Snapchat records each memory's capture time, and MemoriesExport applies it so your memories sort in the correct order rather than collapsing onto one day. One honest limit: for several memories captured on the same day, Snapchat's export gives no per-item join key, so the exact minute-by-minute order within that day can't always be reconstructed — the day is right, the second-level order within it may not be.
My export shows the year 2052 (or some other far-future date). Same fix?: Yes. A wildly wrong year is the same root cause — a garbage fallback date because the file has no real capture date inside it. Writing the true date from the JSON replaces it.