Renaming files from a spreadsheet
When the new names come from somewhere else — a client's list, an export, a stock database — no pattern rule helps. You need a mapping, and the failure modes are specific.
Pattern-based renaming handles most jobs: add a prefix, insert a date, renumber. It cannot handle the case where the new names are arbitrary and come from somebody else.
A client sends a spreadsheet mapping product codes to descriptions. A photographer needs image files renamed to match a catalogue. A migration needs document IDs mapped to human-readable titles. There is no rule that derives SKU-40192.jpg → winter-coat-navy-large.jpg. The relationship only exists in the spreadsheet.
The shape of the job
You need two columns: current name, new name.
old,new
IMG_4471.jpg,winter-coat-navy-large.jpg
IMG_4472.jpg,winter-coat-navy-medium.jpg
IMG_4473.jpg,scarf-grey.jpg
Everything else is detail. The detail is where it goes wrong.
Preparing the list without creating problems
Include the extension, consistently. Decide whether your new column contains .jpg or not, and be consistent. Half with and half without produces files with no extension, which macOS will then refuse to open.
Watch for invisible whitespace. A trailing space in a spreadsheet cell is invisible and produces a filename ending in a space — which macOS tolerates and Windows does not, and which makes the file hard to reference from scripts. Trim every cell before exporting.
Export as UTF-8. If names contain Turkish, accented or non-Latin characters, an export in the wrong encoding turns şirket into Åirket. Check one row after exporting, before renaming four hundred files.
Check for duplicate targets. Two rows producing the same new value is the most common failure in this job. One file overwrites the other, or the tool appends a number, and either way you now have files whose names do not match the list. Sort the new column and look for repeats before you start. A spreadsheet conditional-format for duplicates takes ten seconds.
Check for missing sources. Rows referring to files that are not in the folder, and files in the folder with no row. Both are normal — a partial delivery, an extra file — but you want to know which is which before rather than after.
Beware of spreadsheet helpfulness. Excel and Numbers reformat things that look like numbers or dates. A product code like 04-2026 becomes a date. A code like 0012 loses its leading zeros. Set the columns to text before pasting, or export from the source as CSV and never open it in a spreadsheet at all.
The order problem
A tempting shortcut is to skip the mapping and just apply a list of new names in order — first file gets first name, and so on.
This works only if the sort order of the files exactly matches the row order of the list, which is a much stronger assumption than it appears. IMG_10.jpg sorts before IMG_2.jpg as text. One extra file in the folder shifts everything after it. A hidden .DS_Store can be counted.
Matching by name is slower to prepare and correct. Matching by position is fast and silently wrong.
Chained renames, which is the subtle one
If your mapping includes a.jpg → b.jpg and b.jpg → c.jpg, the order of operations decides the outcome. Rename a first and it overwrites b before b has been renamed. The original b is gone.
Tools that handle this properly detect the cycle or stage renames through temporary names. Tools that do not will lose a file, quietly. If your list involves any name appearing in both columns, this applies to you.
Before you run it
Copy the folder. This operation is harder to reverse than a pattern rename, because the original names are not derivable from the new ones — the mapping only goes one way unless you kept the spreadsheet.
Keep the spreadsheet. It is your undo.
Doing this with RenameDeck
RenameDeck can import a prepared list or CSV and rename from it, which is the mechanism this whole article needs and which Finder has no equivalent of.
The safeguards line up with the failure modes above. You get the full result list before anything is renamed, so duplicate targets, missing sources and encoding damage are visible as proposed names rather than discovered afterwards. It detects invalid names and collisions, and never overwrites an existing file — which is the protection against the chained-rename case above.
Journaled transactions and identity-protected history support recovery and eligible undo, so a mapping that turns out to be wrong is not necessarily permanent.
For a job you repeat — a client who sends a new batch monthly — the import can be part of a saved recipe alongside case and template rules, and assigned to a trusted folder.
The app is sandboxed with no network entitlement, so neither your files nor the spreadsheet you imported leaves the Mac. Requires macOS 14 or later.