The date on the file is not the date of the photo. The right one is inside the file, and it survives everything the wrong one does not.
You have three thousand files called IMG_6763.HEIC and no idea which is which. The fix is to put the capture date in the name. The trap is that macOS shows you at least three different dates for every photo and only one of them is the one you want.
A photo on your Mac carries several timestamps:
There are two near-neighbours that are not the same thing. DateTimeDigitized (sometimes shown as CreateDate) is when the image was digitised, which for a digital camera equals the original but for a scan is the scan date. DateTime (ModifyDate) is when the file was last written by software, so an edit in Photos moves it. Use DateTimeOriginal, and fall back to DateTimeDigitized only when it is missing.
Screenshots and downloads have no EXIF date. A screenshot, a WhatsApp save, a Facebook download and most social images arrive stripped. If a batch produces a handful of files that will not rename, check whether those files simply have no DateTimeOriginal to read. A good tool skips them and tells you rather than falling back to the file date silently.
You do not need to install anything to look. In Preview, open the image, then Tools, Show Inspector, and the EXIF tab. The field is listed there.
If you have exiftool installed, one file at a time in Terminal:
exiftool -DateTimeOriginal -CreateDate -ModifyDate IMG_6763.HEIC
Do this on two or three files from each source (phone, DSLR, scans, downloads) before running anything across the whole folder. Sources differ and they differ in exactly the ways that ruin a batch.
The only format worth using starts with the year and goes down in size:
2026-09-12 14-33-08.heic
2026-09-12 14-33-08 IMG_6763.heic
09-12-2026 2.33pm.heic
Reasons, in order of how much they will matter to you later:
09-12 is September the twelfth to an American and the ninth of December to everyone else. 2026-09-12 is one thing.14-33-08, not 14:33:08.Keeping the original camera name on the end, as in the second example, is worth doing. It gives you a tiebreak for photos taken in the same second, and it keeps a thread back to the original if you ever need to match against a backup.
Classic EXIF DateTimeOriginal has no time zone in it. It is a wall clock reading: the time the camera thought it was. Two consequences:
exiftool first, then rename.Modern iPhones do write OffsetTimeOriginal alongside, which records the UTC offset. Good tools read it. If exact ordering across time zones matters to you, check that yours does before you commit a trip's worth of files.
For almost everyone the wall clock is what you actually want. The photo of dinner in Tokyo taken at 8pm should say 8pm.
Live Photos are two files, a .HEIC and a .MOV, paired by an identifier inside them rather than by the filename. Renaming both to the same base name does not recreate the pairing, and renaming one does not break the pair inside the Photos library, because the library tracks them separately. What it does break is any app that pairs them by name on disk. If you care about keeping Live Photos live, export them from Photos as Live Photos and leave them alone rather than renaming exported pairs.
HEIC is fine to rename. It carries EXIF exactly like JPEG does. The only thing to watch is that some older tools read the container but not the EXIF block and report no date at all, which is a tool problem, not a file problem.
Bursts are the case that exposes a weak renamer. Ten frames can share the same second, so a name built from date and time alone collides ten ways. Either include the original filename, or use a tool that appends a sequence number when a destination is already taken. Collision handling is the single most important thing to check, because the failure mode is files overwriting each other rather than an error message.
Do not work inside the Photos library. Photos Library.photoslibrary is a package with its own database, and renaming files inside it corrupts the library. Export first, rename the exported copies, and keep the library out of it.
This is the case the app was built for. It reads DateTimeOriginal out of the image with ImageIO, so HEIC, JPEG and raw all work the same way, and it builds the name from a template you set once. The preview is the whole batch before anything moves, collisions are computed against the final state rather than file by file, and the last saved session can be undone.
It runs on the Mac and on the iPhone and iPad, which matters more than it sounds: renaming the photos on the phone before they ever reach the Mac means the Mac side is already clean.
None of that is required to follow the rest of this page. Read DateTimeOriginal, sort-friendly format, keep the original name as a tiebreak, preview before you commit.
I write media tooling. Media Renamer Pro is my Mac, iPad and iPhone app that does the renaming described here, with a full preview before anything moves and undo for the last saved rename session.
None of the above requires it. The rules are the rules whatever you use.
Related: batch renaming safely · renaming over SMB and NAS