First, Decide What Kind of Rename This Is
Before you open anything, put the batch in one of two buckets, because they need completely different tools. A pattern job means the new name can be worked out from the old name plus a rule you can state in words: lowercase everything, swap spaces for underscores, strip a trailing counter, stamp a date on the front. A content job means the new name has to come from information that lives inside the file, not in its current name: the vendor on a scanned invoice, the subject of a photo, the title of a contract. Pattern jobs are what Finder, Terminal, and Automator are for. Content jobs are the one thing all three fundamentally cannot do, and we get to that at the end.
The other axis is scale and repetition. A one-time batch of a few hundred files with a clean rule is a Terminal one-liner. A rename you run every week is worth saving as an Automator Quick Action so it becomes a right-click away. Sorting the batch on these two questions first saves you from fighting the wrong tool for twenty minutes.
Yes, Finder Can Do It, Up to a Point
For completeness: Finder's built-in Rename dialog (select the files, right-click, then Rename X Items) handles find-and-replace, prefixing or suffixing, and rebuilding names with a counter, and for small-to-medium batches with a simple rule it is the fastest thing on the machine. If that is your situation, use it and stop reading. This page exists for the batches Finder starts to strain on: thousands of files, rules that need regex or conditional logic, and renames you have to repeat on a schedule. For those, the rest of macOS has better tools that most people never open.
Terminal: The Workhorse for Large and Regex Batches
The macOS Terminal renames files faster than any dialog and does not care whether the batch is ten files or ten thousand. Open Terminal, then cd into the folder holding the files, and reach for one of three patterns depending on the job.
The first pattern is the shell for-loop with mv, which is the general-purpose tool. To replace every space in a batch of filenames with an underscore, run for f in *; do mv "$f" "${f// /_}"; done. That uses zsh and bash parameter expansion, where ${f// /_} means "take the value of f and replace every space with an underscore", no external command needed. To lowercase every name, run for f in *; do mv "$f" "$(echo "$f" | tr '[:upper:]' '[:lower:]')"; done. In plain terms, one messy export like Final Report (2).pdf comes out the other side as final_report_2.pdf once you combine the space and case rules.
The second pattern is the dedicated rename command, which is cleaner for anything regex-shaped. It does not ship with macOS, so install it once with Homebrew by running brew install rename. After that, a rule like rename 's/ /_/g' * replaces spaces with underscores across every file in the folder in a single call, and rename 'y/A-Z/a-z/' * lowercases them. The s/// and y/// syntax is Perl-style substitution, so "remove everything after the second dash" or "strip a trailing (1), (2), (3)" becomes a one-line expression instead of a hand-written loop.
The third pattern is zmv, a rename tool built into zsh (the default Mac shell) that nobody advertises. Turn it on for the session with autoload -U zmv, then move files with a match-and-replace pattern, for example zmv '(*).txt' '$1.bak' to change every .txt extension to .bak, where (*) captures the base name and $1 replays it. zmv is the most forgiving of the three about spaces and special characters, which is exactly what breaks naive loops.
Two Habits That Keep Terminal From Ruining Your Day
Terminal has no undo and no confirmation. That is the whole reason to build two reflexes before you run anything for real. The first is the echo dry-run: put echo in front of mv (for f in *; do echo mv "$f" "${f// /_}"; done) so the loop prints what it would do without touching a single file. Read the output, confirm the before-and-after looks right, then remove echo and run it for keeps. The rename command has its own version of this, the -n flag, so rename -n 's/ /_/g' * previews the renames and changes nothing.
The second habit is quoting your variables. Always write "$f", never bare $f. A filename with a space in it, and Mac filenames are full of them, splits into two arguments the moment it is unquoted, and the rename either fails or clobbers the wrong file. Quote everything, dry-run first, and keep a duplicate of the folder the first few times, and Terminal goes from scary to routine.
Automator: Save a Recurring Rename as One Right-Click
When it is the same rename every week, the export batch off a camera, the monthly folder of statements, you do not want to retype a Terminal command or re-fill a dialog each time. Automator lets you build the rename once and pin it to Finder's right-click menu as a Quick Action.
Open Automator, choose New Document and then Quick Action. Set "Workflow receives current" to files or folders in Finder. Drag the Rename Finder Items action into the workflow and configure it the way you would Finder's dialog (add a date prefix, replace text, or apply a counter). Save it with a clear name like Prefix With Date. From then on, the whole thing is one gesture: select the files in Finder, right-click, open Quick Actions, and pick Prefix With Date. Each Rename Finder Items action does a single transformation, so stack two of them when you need, for example, replace text and then add a counter, and remember the steps run top to bottom. Automator is the middle ground between the one-shot dialog and raw Terminal: repeatable, but nothing to memorize.
The One Thing None of These Can Do: Rename by Content
Every method above shares a blind spot. Finder, Terminal, and Automator all rename by manipulating the filename that already exists. They never open the file. That is fine when the new name can be derived from the old one, and useless the moment the name has to come from what is inside.
The batch that exposes this is the document backlog, which is exactly the kind of large, recurring job that sends people looking for a bulk-rename solution in the first place. Picture a folder of scanned purchase invoices named scan_0001.pdf through scan_0400.pdf. No pattern rule can turn scan_0087.pdf into 2026-02-11_Northwind_Invoice_4471.pdf, because the date, the vendor, and the invoice number are printed on page one, not encoded in the current filename. A for-loop can lowercase scan_0087.pdf; it cannot read it.
This is the case a content-based renamer exists for. Unlike rule-based renamers that only see filenames, renamer.ai reads the actual document content (OCR + AI vision) to generate descriptive names automatically. You point it at the folder, set a template such as date, vendor, then invoice number, and it proposes 2026-02-11_Northwind_Invoice_4471.pdf for that scan and a matching name for every other file in the batch, then you review and apply. For an at-scale document backlog, that is the difference between a rename you can automate and one you would otherwise do by opening 400 PDFs by hand. This is the situation where dedicated bulk rename software does something the native Mac tools cannot.
Which Method for Which Batch
Here is how the four approaches line up across the questions that actually decide which one to reach for.
| Approach | Best for | Handles regex? | Reusable? | Reads file content? |
|---|
| Finder Rename dialog | Small to medium batches with a simple rule | No | No | No |
| Terminal (loop, rename, zmv) | Large batches, regex, conditional logic | Yes | As a saved script | No |
| Automator Quick Action | The same rename repeated on a schedule | Limited | Yes (right-click action) | No |
| Content-based renamer | Naming scans and documents after what is inside | N/A | Yes (saved template) | Yes (OCR + AI vision) |
Read the table top to bottom as a decision path. If the rule is simple and the batch is small, Finder wins on speed. As the batch grows or the rule needs regex, move to Terminal. If you will run it again next week, save it in Automator. And if the name has to come from inside the file, none of the first three apply, and only a content-reading tool will get you there.
Scanned Documents and Why OCR Is the Deciding Factor
There is a trap worth naming inside the content-based case: a scanned document is not text, it is a picture of text. When a scanner produces scan_0087.pdf, the invoice number printed on the page is a pattern of pixels, not characters a program can read. That is why even a tool that tries to read content comes up empty on raw scans unless it does one more thing first. OCR (optical character recognition) is that step, turning the image of a page back into machine-readable text. Renamer.ai runs OCR as part of reading each file, so a scanned invoice gets named after its content the same way a born-digital PDF does. If your at-scale batch is scans, this is the single capability that decides whether a tool can help at all, and no filename-based method, Finder, Terminal, or Automator, will move the needle on it.