EXIF Date vs File Date: Which One Do Photos Use?

By Josep Mampel Marques, updated November 11, 2026

EXIF DateTimeOriginal is the date and time the photo was taken, stored inside the file. The file's modified date is a separate value kept by your operating system, and it changes when a file is copied, downloaded or saved again. Apps that read metadata sort by the EXIF date when it exists; the file date is only a fallback, and it is the one Google Takeout gets wrong. Most "wrong date" problems come from a photo that has the file date but no EXIF date.

The dates inside the file (EXIF)

ExifTool's tag documentation, which follows the EXIF specification, lists three main dates:

For a camera or phone photo, the capture time is DateTimeOriginal. The other two are less clear-cut, and ExifTool's page does not give them a separate description, so a safe habit is to look at DateTimeOriginal first. There are also time zone fields: ExifTool lists OffsetTimeOriginal as the time zone for DateTimeOriginal and OffsetTime as the one for ModifyDate. A date without an offset is a local clock time with no zone attached, which is why the zone matters when a tool has to write a date from Google's data.

The date outside the file

The file modified date (and the creation date shown by some systems) is part of the file system, not the image. Google's help notes that your operating system may give a downloaded photo or video a new timestamp, and that the original timestamp stays in the embedded metadata. Copying files between drives, downloading and unzipping can all change it. A photo's EXIF date can survive all of that; the file date usually cannot.

Why this breaks Google Photos exports

Google Photos knows the capture date of every item, including those that never had an EXIF date, such as screenshots, WhatsApp images and files saved from the web. In a Takeout, extra metadata goes into a separate JSON file next to each file. Another app reading only the image sees no EXIF date, falls back to the file date and files the photo under the day you exported. The JSON side is explained in Google Takeout JSON files explained, and the symptoms in why Takeout photos have the wrong date.

How to look at both dates

• File date. Your file manager's Date modified column.
• EXIF date. The photo's properties or info panel. Many systems label it "Date taken". ExifTool, if you use the command line, prints DateTimeOriginal, CreateDate and ModifyDate.

If the two differ by years and the EXIF value matches your memory, the file date is the damaged one. If the EXIF date is missing, no app can know when the photo was taken without a JSON file or another source.

Which date should be right

1. EXIF DateTimeOriginal should hold the capture time with a time zone, because that is what apps read.
2. The file modified date should match the capture time too, so that plain folder sorting and tools that only look at file dates behave.
3. Videos have no EXIF block, so their creation date lives in the container.

Putting both back

PhotoFixer does exactly this to a Takeout, in your browser and without uploading anything. For JPEG photos without EXIF it writes the date (with the time zone offset you choose), the location and the description from the .json. JPEG photos that already have EXIF keep everything they have and only get the fields they lack. MP4 and MOV videos get their creation date, and every file in the result zip gets its capture time as the file date. HEIC photos keep their own date and are copied unchanged, with the correct file date. The time zone you pick matters because Google stores the time in UTC and EXIF needs local time.

If you are checking a result, pick a screenshot, a photo from the camera, and a video, and compare both dates. To see how a fixed copy can be copied to a NAS or drive, see Google Photos to Synology.