Rename Google Photos Files by Date After a Takeout Export
Turn IMG_20190714_110530_1.jpg into 2019-07-14-1105_Paris.jpg using the real date from the Takeout sidecar, with names that sort right everywhere.
A Google Photos export gives you back every filename your phones and cameras ever made up. IMG_20190714_110530_1.jpg, PXL_20210813_143022914.jpg, DSC_0042.JPG, IMG-20180402-WA0007.jpg, Screenshot_2019-03-03.png. Sorted by name, one holiday is scattered across the folder. Sorted by date, everything is the day you unzipped.
Renaming by date fixes both, as long as the date comes from the right place.
Why the names are like this
Google never renamed anything. It stored what your device uploaded and gave it back. Ten years of devices means ten naming schemes, and some of them do not sort in time order even among themselves. DSC_0042 from 2015 sits next to DSC_0042 from 2019.
Takeout adds its own noise. A second upload of the same name becomes IMG_1234(1).jpg. A photo you cropped inside Google Photos comes out twice, as IMG_1234.jpg and IMG_1234-edited.jpg. Long names get shortened in the sidecar but not in the photo.
Where the date must come from
A rename tool needs a date to put in the name. It can read the file's modified date, the EXIF date inside the photo, or the Takeout sidecar. Only the last one is reliable for an export.
The file date is the moment you unzipped. Rename by that and every photo gets today.
The EXIF date is right for photos straight off a phone camera, and missing for screenshots, WhatsApp images, scans and anything you re-dated inside Google Photos. Rename by EXIF and those get skipped or get today.
The sidecar, IMG_1234.jpg.supplemental-metadata.json, holds the real photoTakenTime for every single file. So the rename either has to read the sidecar, or you write the sidecar date into EXIF first and rename from EXIF afterwards. Google Takeout photos show the wrong date covers the write-into-EXIF step.
A name that sorts everywhere
Put the biggest unit first and pad everything with zeros:
2019-07-14-1105_Paris.jpg
2019-07-14-1132_Paris.jpg
2019-07-15-0908_Versailles.jpg
Year, month, day, then time to the minute. This sorts correctly as plain text in Finder, Explorer, a Linux file manager, a NAS web page, a TV and a terminal. No metadata needed. Use 1105, not 11:05, because colons are not allowed in filenames on Windows or macOS. If two photos share a minute, a counter goes on the end, _1, _2.
The place name is optional but useful. It comes from the GPS in the sidecar, turned into a town name. _Paris tells you more at a glance than _IMG_4821 does. If you would rather keep the original name for matching against old backups, put it after the date, as 2019-07-14-1105_IMG_4821.jpg. The date still controls the sort. Rename photos by date taken in bulk goes deeper on schemes.
Doing it with exiftool
Two steps. First write the sidecar date into EXIF:
exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" \
"-DateTimeOriginal<PhotoTakenTimeTimestamp" \
-ext jpg -ext jpeg -ext png -ext heic -overwrite_original "Takeout/Google Photos"
Then rename from EXIF:
exiftool -r "-FileName<DateTimeOriginal" -d "%Y-%m-%d-%H%M%%-c.%%e" "Takeout/Google Photos"
The %%-c adds -1, -2 when two photos share a minute, and %%.e keeps the extension. exiftool renames in place and has no true dry run, so try it on a copied folder first.
The catches are the usual Takeout ones. Truncated sidecar names and (1) duplicates do not match the %F pattern, videos need different tags, and -edited files have no sidecar. The exiftool guide walks through each. Place names are not something exiftool can add; that needs a lookup from coordinates to a town, which means a script or a different tool.
One more thing to watch. A Live Photo is a still plus a short clip with the same name, and Apple Photos and Immich pair them by that name. Rename the still and not the clip and the pair is broken. Rename both with the same pattern in the same command.
Doing it with the app
Takeout JSON Metadata Fixer reads the sidecars directly, so there is no two-step, and it adds the place name.
Point it at the zips or the unpacked folder and pick a naming template. Date-Time + Location gives 2019-07-14-1105_Paris.jpg. Date-Time Only gives 2019-07-14-1105.jpg. Original + Date-Time keeps the camera's name and adds the date, IMG_4821_20190714_1105.jpg. Keep Original Name leaves names alone if all you wanted was the dates fixed. You can add your own prefix or suffix, so a batch can start with Wedding_.
The date for each name comes from the sidecar first, then EXIF, then the file date as a last resort, and the app writes the same date into the file's EXIF and timestamps at the same time. So the name, the EXIF and the file date agree. Live Photo pairs get the same new name. Duplicates in album folders are recognised and not copied twice.
Dry run shows every proposed name before anything is touched. When you organize a folder in place, the untouched files can go into an "Originals (before organizing)" folder so you can compare. It runs on macOS, Windows and Linux, offline. Free for 500 photos, $9.99 once for unlimited.
Frequently asked questions
Should the time be local or UTC?
Local, the time on the clock where you stood. The sidecar stores UTC, and tools convert using your computer's time zone. Set your computer to the zone most of your photos were taken in before renaming, or accept a few hours of drift on trips abroad.
What happens to the .json files when the photos are renamed?
exiftool leaves them with the old names, which is fine once the dates are inside the photos. The app does not copy them to the organized folder unless you ask for sidecars for Immich or PhotoPrism, in which case they get the new names too.
Will the place name be right?
It is the nearest town or city to the GPS point, looked up from OpenStreetMap. Photos without GPS get no place in the name. A photo taken on a train may get the nearest village rather than where you were going.
Can I undo a rename?
Not with exiftool, unless you kept a copy. The app writes to a destination folder or keeps originals in a safety folder, so the source stays as it was until you delete it yourself.