Batch rename files on a Mac without losing the originals

Everything written about how to batch rename files on a Mac covers the mechanics: select, right click, choose Rename, fill in three fields. The mechanics take about fifteen seconds to learn. What takes longer to learn is the part that comes after a bad run, when four hundred files carry the same wrong prefix, the folder no longer sorts the way it did, and something else that pointed at the old names has quietly stopped working.

The risk in bulk renaming is not the individual rename. It is that a small error is applied identically to every file, and that almost nothing on the system announces the damage. This is about making the operation reversible before running it, rather than about which tool to run.

An error that repeats is a different kind of error

Renaming one file wrong is visible immediately. Renaming four hundred wrong produces a folder that looks fine at a glance, because every name is consistent with every other name. Consistency is exactly what was asked for, so nothing looks out of place.

Three failures account for most of the trouble.

The first is a pattern that matches more than intended. Replacing "2025" with "2026" also rewrites a client name containing that string, an invoice number, and a version suffix. The replacement in Finder is a plain text substitution with no word boundaries, so anything that contains the text is fair game.

The second is a collision. Two files reduced to the same name cannot coexist in one folder. Finder stops and reports it, but a terminal mv does not: the second file overwrites the first, and the first is gone without a trip to the Trash.

The third is scope. A selection made in a search results window, or in a window showing a flattened view, can span several folders at once, and the rename applies to all of them. The count shown in the rename sheet is the only confirmation of how many files are about to change, and it is worth reading every time.

Read the result before it happens

Every route has a way to see the outcome first, and all three take seconds.

In Finder, the Rename Finder Items sheet shows an example line at the bottom, built from the actual first item in the selection. It updates live as the fields are filled in. If that line is not what was wanted, nothing has happened yet.

On the command line, the zsh rename function has a dedicated flag for it. After autoload -U zmv, running zmv -n '(*).txt' '$1.md' prints every rename it would perform and changes nothing. The -n stands for no execution, and it is the difference between a tested pattern and a hopeful one.

The third method works regardless of tool. Duplicate the folder with Command+D, run the rename on the copy, look at the result, then delete whichever version turned out wrong. On a folder of documents this costs disk space for a minute. On a folder of raw video it is impractical, which is when the first two methods matter more.

Keep a record that can undo the rename

Undo inside an application is short lived. A written list of the old names is not, and it takes one command.

cd ~/Documents/invoices
ls > ../before.txt

For something that can actually reverse the operation, record pairs rather than a plain list. Running this before the rename writes a file mapping each name to itself, which becomes the reference for rebuilding the originals:

for f in *; do printf '%s\t%s\n' "$f" "$f"; done > ../names-before.tsv

The value of the list is that it survives everything: quitting the application, restarting the Mac, discovering the problem a week later. The moment to write it is before the rename, and there is no later opportunity, because once the names are gone there is nothing left to record. On files that have been copied from a camera or downloaded, the original name is often the only remaining link to where the file came from.

Undo, and the exact point it stops working

Finder supports undo for a bulk rename. Pressing Command+Z immediately after restores every name in that operation, and it works even after the selection has been changed or another folder has been visited. What it does not survive is a Finder relaunch, a logout, or a second, third and fourth operation pushing it off the undo stack.

There is no equivalent anywhere else. A rename in Terminal is a filesystem operation with no history, and no tool watches it. The same is true of Automator and Shortcuts workflows, which perform the rename through the same underlying call.

Route	Undo available	Behaviour on a name collision
Finder rename sheet	Command+Z, until Finder relaunches	Stops and reports the conflict
Terminal mv	None	Overwrites the existing file silently
Terminal mv -n	None	Skips the file and leaves both intact
zsh zmv	None	Refuses unless the force flag is given
Shortcuts or Automator	None	Depends on the action settings

The practical reading of that table is to add -n to any mv used in a loop, and to treat zmv without the dry run flag as the same class of operation as deleting files.

What else is pointing at those names

A filename is not only a label. Other things store it, and they do not all survive a change.

What points at the file	Survives a rename	Why
Finder alias	Yes	Stores a file identifier as well as a path
Symbolic link	No	Stores only the path text
Recent items and reopened documents	Usually	Bookmark data can resolve by identifier
Relative links inside documents	No	Markdown, HTML and spreadsheets store the text
Version control	Yes, with a caveat	Git detects renames by content once both sides are staged
Photos and Music libraries	No	Renaming inside the library package breaks the catalogue
Path based backups	Technically yes	The renamed file is treated as new and copied again
Cloud sync folders	Yes	Every renamed file becomes a change event to upload
Spotlight index	Yes	Reindexed automatically, though not instantly

Two rows deserve attention before a large run. Renaming several thousand files inside a synced folder produces several thousand change events, and the sync client will be busy for a while, which is a reason to run it when nothing else depends on that folder. And a rename inside a Photos library, or any other package that keeps its own catalogue, should not be attempted at all: the fix is to rename inside the application that owns the library.

Names that pass today and break later

macOS accepts almost anything, which is not the same as everything downstream accepting it.

You can use numbers and most symbols. You can’t include a colon (:) or start the name with a period (.). Source: support.apple.com

Beyond the two rules Apple states, four limits cause trouble later rather than at the moment of renaming.

• The filename limit is 255 characters. A long prefix added to already long names truncates or fails partway through a batch.
• The default disk format is case insensitive, so Report.pdf and report.pdf collide even though they look distinct.
• A trailing space is accepted and invisible, and it breaks any later match on the name.
• Characters that are legal here are rejected on other systems. A file with a question mark or an asterisk in its name cannot be written to most Windows shares or unpacked cleanly from an archive on one.

The safe set for anything that leaves the Mac is letters, numbers, hyphen, underscore and a single dot before the extension. Dates in a numeric year, month, day order sort correctly with no extra work, which removes the need to rename the same files again later for sorting.

Checking the result instead of trusting it

A rename that ran without an error message has not necessarily done what was intended. Three checks catch nearly everything, and none of them take more than a few seconds.

Start with the count. If the folder held four hundred items before and holds four hundred after, nothing was overwritten. A drop means files were replaced by others carrying the same new name, and the number missing is the number lost. The status bar in Finder shows this figure once it is enabled, and ls | wc -l gives the same answer.

Next, look for the items the pattern skipped. A rename that was meant to apply to everything but only matched most of it leaves a folder in two states, which is worse than one that failed outright, because a later pass over the same folder then treats the already renamed files as if they still needed changing. Sorting by name puts the two groups in separate blocks and makes the split obvious at a glance. On the command line, listing everything that does not match the new convention answers it directly:

ls | grep -v '^2026-'

Finally, compare against the record written earlier. With a before list saved outside the folder, a single command shows exactly what changed:

ls > ../after.txt
diff ../before.txt ../after.txt

The output of that comparison is the honest report on the operation, and it is the only one available once the undo has expired. Lines prefixed with a minus are the names that no longer exist, lines with a plus are the new ones, and the two counts should match. When they do not, the difference is the set of files that collided, and the names on the minus side are the ones to look for in a backup.

An order of operations worth fixing in place

The sequence matters more than the tool. This works for ten files and for ten thousand.

1. Open the folder in list view and read the item count in the status bar.
2. Write the before list to a file outside the folder.
3. Preview: the example line in the sheet, or the dry run flag.
4. Run the rename on five files first, chosen with the Command key.
5. Check those five, including one with an unusual name.
6. Run the rest.
7. Check the count again. It should not have changed.

Step seven catches the collision case, which is the failure that actually loses data. A folder that held four hundred files and now holds three hundred and ninety six has lost four of them to overwriting. The FAQ page covers the recovery questions that follow from that, and the features overview sets out how a file window that includes a shell handles the dry run and the check without leaving the window.

What to change first

Write the before list, then preview, then run five before running all. That habit costs under a minute and covers every failure described here. If the awkward part is that previewing means one window and renaming means another, the window itself is what to change, and Atriens exists for that.