Bulk rename files on a Mac: a naming rule you can repeat

A folder of two hundred files named Scan 2026-09-14 at 11.02.13.pdf and IMG_4471.HEIC is not a naming problem. It is a decision that was never made. Finder will happily rename all two hundred in one pass, and forty files later the same folder looks exactly as it did before, because nothing decided what the next file should be called. The tools for bulk renaming on a Mac are good and there are more of them than most people use. The part that actually determines whether the folder stays readable is the rule, not the tool.

What follows covers what Finder's built in rename can and cannot do, what the terminal adds, what a dedicated app is worth paying for, and the naming shape that keeps a folder sorted correctly a year from now.

Two different jobs get called the same thing

"Bulk rename" describes two tasks that need different answers.

The first is a one time cleanup. A camera dumped four hundred files with sequential numbers, or a scanner used timestamps, and the goal is to get through it once and never think about it again. Finder handles this well and nothing else is needed.

The second is a rule applied repeatedly. Invoices arrive every month, screenshots accumulate every day, exports land in Downloads every Friday. Renaming them by hand each time is the same work done forever. Here the useful output is not renamed files, it is a saved rule: a shell function, an app workflow, or a folder action that applies the same transformation without anyone deciding again.

Most frustration with Mac renaming comes from using the first tool for the second job. Finder's rename dialog does not save what was typed into it. Close the window and the pattern is gone. That is fine for a one off pass and it is the reason the same folder needs cleaning again in six weeks.

The practical test is simple. If this folder will receive similar files again, the output of the session should be a rule, not a set of renamed files. If it will not, use Finder and stop reading at the next section.

What Finder's rename actually offers

Select several items in Finder, Control-click one of them, and choose Rename. The pop up menu below "Rename Finder Items" offers three modes, and they cover more than their names suggest.

Replace Text takes a Find string and a Replace string. Leaving the Replace field empty deletes the Find string from every name, which is the fastest way to strip a common prefix like Scan or Copy of .

Add Text puts a string before or after the existing name. Useful for stamping a project code onto a set of files that are already named sensibly.

Format is the one that does real work. It builds names from a Custom Format field plus an index, a counter, or a date, placed before or after the name, and it accepts the number to start from. This is how a folder of camera files becomes site-survey-001.jpg through site-survey-400.jpg in one pass.

Two constraints are worth knowing before starting. A filename cannot contain a colon and cannot begin with a period. Apple's guidance is also explicit about three things to leave out of any selection: application folders and items that came with the system, such as the Library folder, the home folder carrying the account name, and filename extensions.

That last item is the trap in practice. If Finder is set to hide them, the visible name of report.pdf is report, and a Format pass that appends anything lands before the extension rather than after it, which is usually what was wanted. If extensions are shown, the extension is part of the name being rewritten and a careless pattern produces report.pdf.pdf. Turn extension visibility on before a bulk pass so the pattern being written is the pattern actually applied.

Finder records the whole rename as one action, so Edit followed by Undo reverses all of it. That single fact makes Finder the right place to experiment.

The naming rule that survives sorting

Finder, ls, and every file dialog sort names as text, one character at a time. Almost every complaint about a folder being unreadable comes from names that sort as text but were written as if they sort as numbers.

Two rules handle it.

Dates go year first, zero padded. 2026-09-26 sorts correctly forever. 26-9-2026, Sep 26 2026, and 9/26/26 all sort by the wrong field. This is not a preference, it is the only date format where text order and time order agree.

Counters are zero padded to a fixed width. file-9 sorts after file-10 because 9 is greater than 1. file-009 and file-010 sort correctly. Finder's Format mode pads automatically when the starting number has leading zeros, so entering 001 rather than 1 is the whole fix.

Beyond ordering, one more choice pays off later. Decide which separator means "field boundary" and which means "space inside a field", then never mix them. A common shape:

2026-09-26_acme-corp_invoice_003.pdf

Underscores separate fields, hyphens sit inside a field, and the fields are always in the same order. A name in this shape can be split by a script, filtered by a Spotlight search, and read by a person, and none of those three need the others to change. Spaces are legal in macOS filenames and cause no trouble in Finder, but they force quoting in every shell command that touches the file, which matters as soon as any of this becomes a saved rule.

Doing it from the terminal

macOS does not ship the rename utility that Linux distributions include, so instructions copied from a Linux answer will fail with "command not found". zsh has its own, and it is already installed.

autoload -Uz zmv
zmv -n 'IMG_(*).HEIC' 'holiday-$1.heic'

The -n flag is a dry run. It prints what each file would become and changes nothing. Drop it only after reading the output. Add that autoload line to ~/.zshrc to have zmv available in every session.

For a pattern zmv cannot express, a loop is clear enough:

i=1
for f in *.pdf; do
  mv -n "$f" "$(printf 'invoice-%03d.pdf' "$i")"
  i=$((i+1))
done

mv -n refuses to overwrite an existing file, which is the guard rail that matters. Without it, two source files that map to the same new name silently leave one file where there were two.

The terminal has one hard limitation and it is not syntax. There is no undo. Finder's rename can be reversed from the Edit menu, and mv cannot. The dry run is the substitute, and treating it as optional is how folders get destroyed. For anything irreversible on files that matter, copy the folder first and run the rename against the copy.

Renaming also needs write permission on the folder, not on the file. A read only file inside a writable folder renames fine. A writable file inside a folder owned by someone else does not, and the error message mentions the file, which sends people to check the wrong thing.

How the options actually differ

	Preview before committing	Saves a reusable rule	Reads photo or audio metadata	Undo	Cost to learn
Finder rename	Partial, one example name	No	No	Yes, one step	Minutes
zsh zmv	Yes, with -n	Yes, in a shell file	No	No	Hours
Dedicated rename app	Yes, full live list	Yes, as a named workflow	Yes	Yes	An afternoon
File manager with a built in terminal	Yes, both at once	Yes, in a shell file	Through command line tools	Depends on the command	Hours

The rows split on one axis: whether the rename is a thing done or a thing saved. Finder is the fastest way to do it once. Everything else exists because the second pass keeps arriving. A note on the last row: the reason to run renames next to the folder rather than in a separate window is that the dry run output and the files it describes are visible together, which is exactly when a wrong pattern gets caught. That difference is easier to judge against the tools it is usually compared with than in the abstract.

What a dedicated rename app adds

Two Mac apps show the range, and they sit at opposite ends of it.

Transnomino is free, at version 10.1.0, and requires macOS 14 or later. It offers find and replace with wildcards, full regular expressions, text insertion at a position, prefixes and suffixes, sequential numbering, trimming, case conversion, diacritic removal, a Windows compatibility conversion, and renaming that applies to the extension or the full path rather than just the name. Actions can be sequenced and previewed as they are built.

Renamer 7 is paid and runs on macOS 15 or later, including macOS Tahoe, as well as Windows 10 and later. Its distinguishing features are reusable saved workflows, chained rules, a live preview of the whole list, undo with file backup, and metadata sources: ID3 tags for music, EXIF and GPS tags for photos, image dimensions, and renaming driven by a CSV file.

That last group is the real argument for buying something. Neither Finder nor a short shell script knows the date a photo was taken or the album a track belongs to. Getting 2024-08-11_kyoto_014.jpg out of IMG_4471.HEIC requires reading EXIF, and an app that already does it is cheaper than the script that would.

Below that line, the honest answer is that Finder plus a dry run covers a great deal, and the feature comparison worth checking is whether preview, saved rules, and metadata are needed at all.

Where bulk renames break

Four failures account for most of the damage.

Hidden extensions. Covered above, and worth repeating because it is the most common one. Show extensions before any Format pass.

iCloud files that are not downloaded. A file in iCloud Drive can exist as a placeholder with no local data. Renaming placeholders usually works, but a script that reads file contents to decide the new name will see nothing. Download the folder first, or restrict the rename to metadata that is available locally.

Name collisions. Any rule that drops information collides. Renaming by date alone turns three files from the same day into one surviving file unless the tool refuses to overwrite. Keep a counter in the pattern and use mv -n or an app with collision handling.

Broken references. Renaming does not update anything that points at the old name. Import statements in code, linked images in a Pages document, playlist entries, and any URL that served the file all break. Files that are referenced by name belong outside a bulk rename, or the references get updated in the same pass. Questions of this shape come up often enough that they are collected in the questions readers send in.

What to change first

Pick the naming shape before touching the files: date first, fields in a fixed order, counters zero padded. Then run one Finder Format pass on a copy of the folder and look at the result before applying it for real. If similar files will keep arriving, the pass is not finished until the pattern lives somewhere it can be run again, which is the argument for keeping folders and a shell in the same place, the way Atriens is put together.