Rename photos by the date they were actually taken
The file's modification date is almost never the date the photo was taken. The real date is inside the image, and using it turns an unsortable folder into a chronology.
You have a folder of images from three cameras, two phones and a WhatsApp export. Sorted by name they are meaningless. Sorted by date modified they are wrong, because copying, editing and exporting all rewrite that date.
The date you want is stored inside the file, and almost nothing in Finder will use it for you.
Three dates, only one of which is true
Every image on your disk has at least three dates attached, and they disagree:
Date Created — when this particular file appeared on this particular disk. Copy a photo from 2019 to a new Mac today and its creation date is today.
Date Modified — when the file was last written. Editing, exporting, or sometimes just a sync client touching it will update this.
Date Taken — DateTimeOriginal in the image's EXIF metadata, written by the camera at the moment the shutter fired. This is the one that never changes unless something deliberately rewrites it.
Finder can show you Date Created and Date Modified. It cannot show you Date Taken, and it certainly cannot rename by it.
Why filesystem dates go wrong so reliably
- AirDrop, cloud sync and messaging apps set the file date to the transfer time.
- Exporting from Photos writes a new file, dated now.
- Unzipping frequently resets dates depending on how the archive was created.
- External drives formatted as FAT32 or exFAT have coarser timestamp handling and time-zone quirks.
This is why "sort by date" on a folder of collected images produces a sequence that has nothing to do with when anything happened.
What a good naming scheme looks like
If you are going to rename by date, use a format that sorts correctly as text:
2026-09-21_142305_Istanbul-rooftop.jpg
Year first, zero-padded, ISO-style. This sorts chronologically in any file listing, in any operating system, forever. 21-09-2026 does not. Sept 21 2026 really does not.
Include the time if you are shooting bursts or merging multiple cameras — two photos taken eleven seconds apart need something to separate them, and a counter is less useful than the actual second.
The multi-camera problem
If you are merging images from two cameras at the same event, check that both were set to the same time zone and roughly the same clock. Cameras routinely disagree by minutes and occasionally by hours, and a chronological rename will interleave them incorrectly.
The fix is to shift one set's times before renaming rather than after — once the times are baked into filenames, correcting them means renaming everything again.
Also be aware that EXIF DateTimeOriginal has no time-zone field in most implementations. It records local time as the camera understood it. For a holiday across time zones, this is either exactly what you want or a source of confusion, depending on whether you think in local time or absolute time.
RAW and JPEG pairs
Shooting RAW+JPEG gives you two files per frame that must keep matching names or your editing software will stop pairing them. Rename both together, from the same source date, in the same operation — never rename the JPEGs and then come back for the RAWs.
Before you run it on four hundred photographs
Test on ten. Check that the dates in the new names match what you expect for images from each source. Images with no EXIF date — screenshots, downloads, anything scanned — need a decision: leave them alone, or fall back to the file date knowingly. A tool that silently substitutes the file date when EXIF is missing will produce a folder where some names are true and some are not, and nothing distinguishes them.
Doing this with RenameDeck
RenameDeck reads image metadata directly and can build names from it, so DateTimeOriginal becomes part of the filename rather than something you look up and type. Dates, image metadata, media tags, PDF properties and parent folder names are all available as sources.
The part that matters for a job like this is the preview: you get the full result list before anything is renamed, so you can see which files got a real capture date and which fell back to something else, and spot the camera whose clock was wrong before you commit. It detects collisions — relevant when two cameras produce the same timestamp — and never overwrites an existing file.
Stack the date rule with a template and a counter, save it as a recipe, and the next card of photos is one click. Journaled transactions mean an eligible batch can be undone properly rather than by memory.
It is sandboxed with no network entitlement, so your photographs and their metadata are read on your Mac and go nowhere.