How to rename iPhone photos by the date they were taken, on a Mac
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.
The dates, and which one is real
A photo on your Mac carries several timestamps:
- Date Modified (filesystem). Changes when anything touches the bytes. Copying, editing, some sync clients, some backup restores.
- Date Created (filesystem). Looks trustworthy and is not. On a copy to another volume, in AirDrop, and in most cloud round trips, this becomes the date of the copy, not the date of the photo.
- EXIF DateTimeOriginal (inside the file). Written by the camera at the moment the shutter fired. It is the only one that means what you want it to mean.
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.
Checking a file before you trust a batch
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.
Pick a name format that sorts
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:
- It sorts chronologically as text. Every file browser, every NAS, every script, forever, with no sort-by-date setting to get wrong.
- It is unambiguous.
09-12is September the twelfth to an American and the ninth of December to everyone else.2026-09-12is one thing. - Colons are illegal in filenames on macOS and Windows both, so times use hyphens or dots.
14-33-08, not14: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.
Time zones, which is where this gets annoying
Classic EXIF DateTimeOriginal has no time zone in it. It is a wall clock reading: the time the camera thought it was. Two consequences:
- Photos taken abroad get local time, not your time. An iPhone updates its clock as you travel, so a photo taken at 9am in Tokyo says 09:00, and it will sort before a photo taken at 10am the same day back home even though it happened first.
- A camera with the wrong clock is wrong forever. If you shot a whole trip with the date unset, every file in it carries the wrong date and no renaming tool can rescue that. Shift them with
exiftoolfirst, 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, HEIC and bursts
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.
A workflow that does not lose anything
- Work on a copy for the first run. Duplicate a folder of a hundred photos and rename those. You will find out what your sources actually contain in about two minutes.
- Preview the full result before anything moves. Not a sample, the whole list, with old and new name side by side. Scan it for blanks, for duplicates and for anything dated 1970 or 2001, which is what a missing date looks like when a tool falls back to something else.
- Handle collisions explicitly. Decide up front whether same-second files get a sequence suffix or keep their original name, rather than finding out mid-batch.
- Check the skips. Files with no EXIF date should be listed and left alone, not quietly renamed from the filesystem date.
- Then run it on the real folder, with undo available for the batch.
Beyond timestamps: human names and Spotlight search
A folder full of dates like 2024-08-12 14-33-08.heic sorts neatly, but it does not tell you what happened. Nobody remembers what they were doing at 14:33. When you need that picture two years later on an external backup or NAS, you search for words like "Tokyo", "Beach", or "Dog".
Media Renamer Pro uses on-device Apple Vision to analyze scenes and generate human-readable descriptions alongside the capture date (e.g. 2024-08-12 Tokyo Vacation.heic). Because the description is part of the actual filename, your photos become instantly searchable using Cmd + Space in macOS Spotlight and Finder, without needing to open a proprietary photo library.
Doing it with Media Renamer Pro
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. It can add on-device Apple Vision scene analysis for human names, compute collisions against the final state rather than file by file, and undo the last saved session.
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.