EXIF Date Taken vs File Modified: a Photo's Three Dates
A photo carries one date inside the file and two on the outside. Which one Finder, Explorer, Apple Photos and Immich read, and how to make them agree.
You sort a folder by date and the order is wrong. You sort by a different date column and it is right. Then you copy the folder to a drive and it is wrong again. Every photo has three dates, and every program picks a different one.
The three dates
Date taken lives inside the file. The camera writes it into the EXIF block when the shutter fires, in a tag called DateTimeOriginal. It is part of the image data, so it travels with the photo through copies, uploads and downloads. Nothing changes it unless a program rewrites the metadata. Screenshots never have one. WhatsApp strips it. Scans get the day of the scan.
Modified date lives on the outside, in the filesystem. It is the last time the file's contents were written. Most copies preserve it. Downloads from a browser, extraction from a zip, and saves from an editor reset it to now.
Created date also lives in the filesystem, and it is the least reliable of the three. On Mac and Windows it becomes the moment the file appeared on this disk, so a copy is "created" when copied. Linux keeps a birth time on ext4 but almost nothing reads it, and ls does not show it.
Videos have a fourth. MP4 and MOV files keep a creation time in their own container, in CreateDate and a few related tags, and they store it in UTC. Photo apps read that rather than EXIF for videos.
You can see all of them at once with exiftool:
exiftool -time:all IMG_4821.jpgWho reads which
Finder, sorting by "Date Created" or "Date Modified", uses the filesystem dates. Its "Date Last Opened" is something else again. Preview's inspector shows the EXIF date. Apple Photos imports by EXIF and falls back to the file date only when EXIF is missing.
Windows Explorer's default "Date" column in a Pictures folder is EXIF date taken when there is one and modified date when there is not. Its "Date modified" column is always the filesystem. Right-click, Properties, Details shows "Date taken" from EXIF. The Photos app sorts by date taken and falls back to modified.
Linux file managers like Nautilus and Dolphin show modified date and sort by it. Image viewers such as gThumb and digiKam read EXIF.
Google Photos, Apple Photos, Immich, PhotoPrism and Android galleries all read EXIF first. When it is missing they use the file's modified date, which is why a screenshot uploaded in 2019 and downloaded in 2026 shows as 2026.
Windows, Mac and Linux all ignore the .json sidecar files that Google Takeout puts beside each photo, and that is the whole Takeout problem in one sentence. The real date is in a file nobody reads.
Why they disagree
They start out agreeing. A photo copied off a phone has the same date in EXIF and in modified, because the phone wrote both at once. Then something resets one of them.
Downloading resets modified and created to now. Unzipping does too. Cloud services sometimes preserve modified on download and sometimes do not. An edit in almost any program resets modified and, depending on the program, may or may not keep EXIF.
Takeout does both things at once. The zip resets the filesystem dates, and for a large share of photos the EXIF date was never there or was corrected only in Google's database. So both visible dates are wrong, and the right one is in a sidecar. Takeout photos out of order shows what that looks like in practice.
Making them agree
The rule is that EXIF is the truth and the filesystem should copy it. EXIF is the only one of the three that survives everything, so it is the one to fix first and the one to copy from.
If the EXIF date is right and the file dates are wrong, one exiftool command copies it outward:
exiftool -r "-FileModifyDate<DateTimeOriginal" "-FileCreateDate<DateTimeOriginal" -overwrite_original .FileCreateDate works on Mac and Windows; Linux ignores it. Afterwards, every file manager sorts the same way as every photo app.
If the EXIF date is missing, you need a source. For Takeout it is the sidecar, and the exiftool guide shows how to write it in. For photos copied off a phone with a program that stripped EXIF, the modified date may be the only surviving record, and fixing dates after copying from a phone covers that case. For scans, you set it by hand.
Do not go the other way. Writing modified date into EXIF only makes sense when you know modified is right, which after a copy or a download it is not.
The app
Takeout JSON Metadata Fixer writes all three dates from the same source so they agree from the start.
For each photo it takes the best date available: the Takeout sidecar if there is one, then EXIF, then the file's modified date. It writes that into DateTimeOriginal and into the file's created and modified times, and into the QuickTime tags for videos. Videos without a sidecar keep their own creation time. Sort by any column in any file manager afterwards and the order is the same.
It works on any folder, not only Takeout exports, so a library that has been through a few copies and downloads can be brought back into line. "Keep names" and "Keep my folders" leaves everything else alone. macOS, Windows and Linux, offline. Free for 500 photos, $9.99 once for unlimited.
Frequently asked questions
Which date does the EXIF store, local or UTC?
Local wall-clock time with no zone, unless the camera also wrote an OffsetTimeOriginal tag, which newer phones do. Video containers store UTC. That is why a video and a photo taken at the same moment can show different hours in a file manager.
Is there a difference between DateTimeOriginal and CreateDate in EXIF?
DateTimeOriginal is when the shutter fired. CreateDate (also called DateTimeDigitized) is when the file was written, which for a camera is the same second, and for a scan is the scan time. Most apps read DateTimeOriginal.
Why does the created date change when I copy a file?
Because it means "created on this volume". Mac and Windows both work this way. It is a property of the copy, not of the photo, which is why it is the worst of the three to sort by.
Does renaming a file change any of the dates?
No. Renaming changes the directory entry, not the file's contents or its timestamps. Moving a file within the same drive does not change them either.