Renaming many files at once on a Mac

Three hundred photographs come off a camera named DSC_0431.JPG through DSC_0730.JPG. A client sends a folder where every file is prefixed with a project code that no longer applies. A set of exports needs a sequence number and a date so it sorts correctly in a shared drive. Renaming them one at a time is an afternoon. Anyone searching for how to batch rename files on mac has already worked that out and is looking for the shortest safe route.

macOS has a capable batch rename tool built into Finder, and most people who ask this question have never opened it. It covers a surprising amount. It also has three clear limits, and knowing where they are is what decides whether the job takes two minutes in a Finder window or needs a command.

What the built in Finder tool covers

Select more than one item in Finder, right click, and the context menu shows Rename with the number of selected items. The dialog that opens has a mode selector at the top left with three options, and each one solves a different shape of problem.

Replace Text finds a string in every selected filename and swaps it for another. Leaving the replacement field empty deletes the string instead, which is how a stale project prefix is stripped from a folder of files. The match is literal, not a pattern, and it is applied to the whole filename including the extension, which is worth remembering before replacing something like a full stop.

Add Text puts a string before or after the existing name. Before is useful for grouping, since a common prefix makes a set sort together. After is where care is needed, because a string added after the name lands between the name and the extension, not at the very end.

Format builds a new name from scratch. A custom format field supplies the base, a name position control puts the index before or after it, and a starting number field sets where the count begins. The format menu offers Name and Index, Name and Counter, and Name and Date. Index counts up in plain integers. Counter pads to five digits, which sorts correctly in every tool that sorts alphabetically. Name and Date appends a timestamp.

That last option carries the single most common surprise in the whole feature. The date the Format mode inserts is the moment the rename runs, not any date belonging to the file. Renaming a folder of holiday photographs with Name and Date stamps every one of them with today, not with the day each was taken. For photographs, that is almost never what was wanted.

The order of the rename follows the current sort order of the window, so switching a folder to list view and sorting by Date Created before opening the dialog is what makes an index sequence come out in chronological order. Sorting by name and expecting chronological numbering is the second most common surprise.

Where Finder stops

Three limits mark the boundary of the built in tool.

There is no pattern matching. Replace Text takes a literal string, so a rule such as "remove any three digit number in brackets" or "keep everything before the first underscore" cannot be expressed. Anything that varies between files has to be handled as a separate pass, and some cases cannot be handled at all.

There is no access to what is inside the file. Nothing in the dialog can read the capture date from a photograph, the artist tag from an audio file, or the title from a document. Every rename is built from the existing name plus text typed by hand.

There is no preview and no dry run. The dialog shows the count of files that will change and nothing else. The result is visible only after the rename has happened. Cmd+Z immediately afterwards does reverse a Finder rename, which is a real safety net, but it has to be pressed before anything else takes the undo slot.

A fourth limit is milder. The dialog operates on a Finder selection, so it works on one folder at a time. Renaming the same pattern across twenty nested project folders means twenty passes.

The terminal version, and the loop worth not writing

The shell answer that appears in every forum thread is a for loop with mv, and it works. It is also the version most likely to cause damage, because mv overwrites an existing file at the destination without asking. A loop that generates a duplicate name silently destroys the file that was already there.

Zsh, which is the default shell on macOS, ships with a better tool. zmv is loaded with autoload -U zmv and takes a pattern and a replacement, using parentheses to capture parts of the old name and $1, $2 and so on to place them in the new one. Renaming every .txt file to .md is one line. Moving the leading date in 2026-01-04-report.pdf to the end is one line. The parts that a for loop makes tedious, such as handling spaces in filenames correctly, are handled by the shell rather than by careful quoting.

Two flags make it safe. -n runs the whole thing as a dry run and prints exactly what would happen without touching anything. -v prints each rename as it goes. Running with -n first, reading the output, then rerunning without it is the habit that makes shell renaming as safe as the Finder dialog and considerably more capable.

For anyone who prefers a dedicated command, a Perl based rename is available through Homebrew and takes a substitution expression directly. It is a different syntax for the same power, and the choice between them is preference rather than capability.

Renaming by what is inside the file

The case that neither Finder nor a plain shell rename can handle is naming files from their own metadata, and it is the case that comes up most often with photographs.

exiftool, installed through Homebrew, reads the capture time recorded by the camera and can write it into the filename directly. A single command renames an entire folder of camera files into a sortable 20260104_143522 form, drawn from each file's own date rather than from today. It handles duplicate timestamps by appending a counter, and it works on video files and audio files as well as stills.

This is worth the setup cost for one reason. A folder of camera files named by capture time sorts correctly forever, merges cleanly with files from a second camera, and survives being copied between machines that would otherwise reorder them. No amount of sequential numbering achieves that, because the numbering is only meaningful inside the folder where it was applied.

For document metadata rather than photograph metadata, the equivalent tools are format specific, and the practical answer is usually a short script that reads the field and calls the rename. That is past the point where a graphical tool helps.

Which route for which job

Route	Pattern matching	Reads file metadata	Preview before running	Cost
Finder Rename Items	No, literal text only	No	No, undo only	Included with macOS
zmv in zsh	Yes	No	Yes, with -n	Included with macOS
exiftool	Through date formats	Yes	Yes, with -o or a test run	Free, installed separately
Dedicated rename applications	Yes	Often, depending on the application	Yes, live preview	Mostly paid
Rule based tools such as Hazel	Yes	Some fields	Yes	Paid

The dedicated applications occupy a real gap. A Better Finder Rename, Name Mangler, and Renamer are all macOS applications built for this single job, and each shows a live preview of the resulting names as the rule is edited. For someone who does complex renames regularly and does not want to write patterns, that preview is worth the licence on its own. NameChanger covers the simpler cases without a purchase.

The gap they fill is narrower than it looks, though. For a one off literal replacement, the Finder dialog is already open and already free. For anything with a pattern, zmv -n gives the same preview in a different form. The applications win when the rule is complex, will be reused, and is easier to build by clicking than by typing.

Making a rename safe

Four failure modes account for nearly every batch rename that goes wrong, and each has a cheap defence.

Collisions are the worst, because they destroy data. Two files that map to the same new name mean one overwrites the other. zmv refuses to proceed when it detects a collision, mv in a loop does not, and the Finder dialog silently appends a number. Preferring the tool that refuses is the whole defence.

Extensions get eaten. Replace Text in Finder matches inside the extension, and a careless pattern in a shell rename drops it entirely. Checking that the dry run output still ends in the right suffix takes two seconds.

Case only changes fail quietly. The default APFS volume on a Mac is case insensitive, so renaming report.pdf to Report.pdf may be treated as renaming a file to itself. The reliable route is two steps through a temporary name.

Scope creeps. A pattern written for one folder, run in the wrong working directory, hits files that were never meant to be included. Running pwd before any recursive rename, and preferring an explicit path over a relative one, prevents it.

The thread running through all four is the same: look at what will happen before it happens. That is one command with -n, and it is the difference between a rename and an incident.

The loop that actually costs time

The rename itself is fast. What takes the time is the cycle around it: look at the folder listing, work out the pattern, switch to a terminal, run the dry run, read the output, switch back to check the folder, adjust, repeat. Each round costs a path copy with Cmd+Option+C and two window switches.

That is a layout cost rather than a tooling cost, and it is the reason a file manager with a built in terminal exists. A folder listing and a command prompt sharing one working directory means the dry run output and the folder it refers to are visible at the same time, which turns four rounds of adjustment into one. The Features page shows how that is arranged, and the Compared with other file managers page places it against the tools that solve the listing and the command separately.

What to change first

Open the Finder rename dialog once and learn the three modes, because a large share of real jobs is a literal replacement that needs no command at all. For everything with a pattern, make zmv -n the habit rather than a for loop with mv, since one refuses to overwrite and the other does not. If the switching between the folder and the command is the slow part, Atriens keeps both in the same window.