Key insights
- Your PDFs come in two kinds, native and scanned, and only a native PDF holds text that a renaming tool can read.
- One Cmd+F search in Preview tells you which kind you have: a scan returns no match for a word sitting in plain view on the page.
- On a mixed folder of 45 PDFs from different senders, not one carried a document title, so the Acrobat title-to-filename recipe would have left all 45 unnamed.
- Batch renamers read the filename, the path and the metadata dictionary, and your vendor name, document number and document date sit in none of those.
- A one-line grep on "Total" matched 13 of those 45 documents and returned a wrong number in 8 of them, because on a two-column layout the line after the label is not the amount.
What renaming a PDF by content actually means
Renaming a PDF by content means reading the text on the page and building the filename from what you find there: the vendor, the date printed on the document, the document number. The name the file already carries is not an input, because a scanner or a download dialog assigned it and neither knew what the document was.
You know the folder. It holds scan_0034.pdf, invoice (3).pdf and Document-2026-03-14.pdf, and not one of those names tells you the supplier or the month. Your computer knows even less. Finder can sort those files by size and by date modified, and both orders are useless for finding an invoice.
Take one file through the process. Before, scan_0034.pdf. After, 2026-03-14_Acme-Supplies_INV-4471.pdf. Three facts were pulled off the page and dropped into a pattern you set once.
2026-03-14comes from the date printed on the invoice, not the date the file was created or downloaded.Acme-Suppliescomes from the vendor name in the letterhead.INV-4471comes from the invoice number, usually the line labeled invoice, reference or document number.- The order, the underscores and the hyphens come from your pattern, not from the document.
Renaming the file changes what your Mac or PC calls it on disk. That is the operation most of this article covers. Changing the title stored inside the PDF is a different job, and the next section separates the two.
If you only need to rename one PDF
One file takes under 10 seconds and needs no PDF software. The filename belongs to your operating system, not to the document. In Finder, select the PDF with a single click, press Return, type the new name, press Return again. In File Explorer, select it, press F2, type, press Enter. On a Mac the rename works while the document is open in Preview. Windows locks a file that is open in a reader, so close it first or File Explorer refuses.
Your reader may still show the old name after that. Compare the window title bar with the name in Finder or File Explorer: a mismatch means the reader is displaying the document title, a metadata field stored inside the PDF, and Word or your export tool filled it with whatever heading the source file had. Acrobat changes it under Cmd+D on Mac or Ctrl+D on Windows, Title field on the Description tab, then Save, and you need a paid plan for that edit. Preview shows the title under Cmd+I but cannot change it. From the command line, exiftool -Title="2026 Q2 fee schedule" "invoice (3).pdf" makes the same edit at no cost and keeps a backup of the original next to it.
That is the whole job for one file. Everything from here on is for a folder of them, where the name you want is printed on the page and typing it 400 times is the problem.
The two kinds of PDF you might be holding
Every method below depends on which of two kinds of PDF you have, and most people never check. A native PDF carries a text layer. A scanned PDF does not. Pick the wrong method for what you are holding and the tool returns blank names across the whole batch. Which one are you holding?
Native PDFs, where the text is already there
A native PDF was exported from something that already held text: Word, Pages, a browser print dialog, or the billing system that generated your invoice. Each character is stored as a glyph in a text layer, an invisible layer of selectable characters behind the page image, and that layer is real data a tool can read out. Invoices that a supplier emails straight from accounting software are native. So is anything you saved with Print to PDF.
Scanned PDFs, where the page is a picture
A scanned PDF is a photograph in a PDF wrapper. It came off a flatbed scanner, a phone scanning app or a fax machine, and no text exists anywhere in the file, only pixels arranged in the shape of letters. You can read it. Software cannot, until OCR has run across it.
How to tell which one you have in 5 seconds
Open the file in Preview and press Cmd+F. Type a word you can clearly see on the page, something from the letterhead, then press Return. If Preview highlights it, the text layer is there and you have a native PDF. If Preview finds nothing while the word sits in plain view, the page is an image and you have a scan.
Drag your cursor across a single word. If you can select just that word, the text layer is there. If your cursor draws a rectangle over the whole page instead, you are looking at an image.
Run that test before you pick a method. Each kind of file breaks in its own way.
| What you have | How to identify it | What a tool can read from it | What breaks |
|---|---|---|---|
| Native PDF | Cmd+F finds a word you can see. You can select one word with the cursor. | The full text of every page, plus whatever sits in the metadata dictionary. | Little. Multi-column layouts and dense tables can scramble the reading order. |
| Scanned PDF | Cmd+F finds nothing. Selecting text draws a box across the whole page. | Nothing at all. Text extraction returns an empty result. | Every text-based method quietly produces blank or identical names. |
| Scanned PDF after OCR | Cmd+F starts finding words. In Preview, the Embed Text option is gone. | The recognized text, at whatever accuracy the scan quality allowed. | Faint scans, stamps and handwriting. Digits are the usual casualty. |
Renaming PDFs without a dedicated tool
Two free routes exist and both work, up to a point: one inside Adobe Acrobat Pro, the other from your command line. Neither is quick to set up, and each fails in a specific way that you only see after the batch has run.
Adobe Acrobat and the Action Wizard
Acrobat Pro can run a script across a folder of PDFs through its Action Wizard. The common recipe pulls the PDF's internal document title and writes it into the filename. This is the sequence you follow, tested in Acrobat Pro on macOS 26.
- Open the Action Wizard. Find it in the Tools pane and choose New Action.
- Point it at a folder. Under Files to be Processed, click Add Files, then Add Folder, then pick the folder holding your PDFs.
- Add the script step. From the More Tools group, add Execute JavaScript to the action list on the right.
- Paste the one-liner. Click Specify Settings and enter
this.saveAs(this.path.replace(this.documentFileName, this.info.Title + ".pdf")) - Save and run. Name the action, save it, then select it from the Actions List and choose your folder.
Run that and every file takes its name from its document title. That is useful exactly as often as the title is correct. On a mixed folder of 45 documents from different senders, not one PDF had a title. Every title field was empty, so this recipe would have handed you 45 blank names and no error.
The saveAs method documented in the Acrobat JavaScript Doc object reference writes a copy under a new name. It leaves the original alone. Run this across 400 files and you end up with 800 files, the original 400 still named exactly as they were. Send the copies to a separate output folder or you will lose track of which is which.
The command line with pdftotext
The other free route reads the page text directly. pdftotext ships with Poppler and installs on a Mac with brew install poppler. Point it at a PDF and it hands back the text layer as plain text. You then filter that down to the one piece you want.
pdftotext -raw scan_0034.pdf - | grep -A 1 "^Total:" | tail -n 1The -raw flag drops the layout reconstruction and returns text in reading order. You anchor the search on a label that sits in a fixed place, Total or Payment Reference or Invoice No, and take the line after it. Wrap that in a shell loop over the folder and you have a batch renamer.
It works for one sender. Every supplier lays out documents differently, so the anchor you built for the first vendor returns an empty string for the second, and you find out which ones failed only after they have run. On that same mixed folder of 45 documents, a Total anchor matched 13 and handed back the wrong number in 8 of those, a line item or a booking reference instead of the amount, because on a two-column layout the line after the label is not the value. Your script did not fail loudly. It returned a plausible string and moved on.
Where the free routes stop paying off
Setup time is the first wall. Building and testing one Acrobat action or one shell script costs you 30 to 60 minutes if you already know the tools. It pays back only when every document in the folder comes from the same sender in the same layout. A folder of 45 documents from 40 senders needs 40 anchors, and writing them takes longer than renaming the files by hand.
The manual alternative has its own arithmetic. 40 PDFs at 20 seconds each of opening, reading and typing is a little over 13 minutes. 400 PDFs is more than 2 hours of unbroken attention, and your error rate climbs long before the end.
Both routes are PDF-only as well. If your folder mixes PDFs with images and Word documents, batch renaming other file types with built-in OS tools is a separate job with separate tools.
Content-based renaming has none of these ceilings. A 4,000-file folder is the same job as a 40-file one, you review a longer list.
Where pattern-based renaming runs out
Everything above shares one limit, and it belongs to no particular tool. It comes from where a PDF stores your data.
Batch renamers read the filename, the path and the metadata dictionary, and the vendor name, the document number and the document date appear in none of those.
The metadata dictionary is the small set of properties a PDF carries about itself: title, author, creation date, producer. Your supplier's system filled those in, left them empty, or set the title to the template filename. On a mixed folder of 45 documents, the usual state was 45 empty titles. You can read the dictionary yourself in Terminal with mdls -name kMDItemTitle -name kMDItemEncodingApplications file.pdf, and the second field, the producer, often tells you which app or scanner made the file. For the full version of this distinction, what separates pattern-based renaming from content-based renaming covers it across every tool class.
Renaming by extracted content
Content-based renaming reverses the order of operations. Rather than reshaping the name you already have, the tool opens the document, reads it, works out what kind of document it is, and writes a name from what it found. The old filename plays no part. Neither does the sender, the language or the layout, because the page is read the way you would read it.
What gets extracted
Four facts carry almost all the value on business documents: the vendor or counterparty, the date printed on the document, the document number, and the document type. You cannot guess any of them from scan_0034.pdf. None sits in a fixed place across senders either. Invoice No, Factuurnummer, Número de factura, Reference: the label changes with the sender and the language, and a content reader has to recognise all of them as the same field.
The document date matters more than it first appears. A file you downloaded in June can be an invoice dated March, so sorting your folder by date modified sorts by the download rather than the document. The printed date also arrives in whatever shape the sender used, 25 May 2026, 9 oktober 2023, 20 de julio de 2023, and a content reader has to normalise all of them to one format before your folder will sort.
One pass over a mixed folder
Drop the folder in and every file goes through the same pass. A native PDF is read directly. A scan goes through OCR first, inside the same run, so you do not sort the folder into two piles beforehand. From each page the reader pulls the four fields above, whatever language the page is in, and writes them into your pattern.
Three files from a folder of 45 show you the shape of the result. Scan 2023-10-09.pdf becomes 2023-10-09_Deltazeker_Autoverzekering.pdf, a Dutch car insurance policy. ticket.pdf becomes 2023-07-20_Abarrotes-Lebron_Receipt.pdf, a Mexican grocery receipt. doc1.pdf becomes 2025-11-07_Wright-Fox-and-Taylor_INV-2025-3511.pdf, a British invoice. One pattern, three languages, no anchor written for any of them.
Building the output pattern
You decide the shape once and every file follows it. A pattern of date, then vendor, then document number produces 2026-03-14_Acme-Supplies_INV-4471.pdf, and because the year leads, your folder sorts chronologically with no folder structure at all.
Put the field you search by first. If you hunt by vendor more often than by date, lead with the vendor instead. Once the names are consistent, filing a backlog of invoices and receipts turns into a sorting job rather than a reading job.
Why review before apply matters
Extraction is a reading task, and reading tasks carry an error rate. A tool that renames 400 files the instant you press go has handed you 400 outcomes you never checked, and finding the wrong ones later means opening files one at a time again. Review before apply puts the proposed name next to the extracted fields for every file, so you scan a list instead of a folder.
Collisions need the same screen. Two invoices from one vendor on one date resolve to the same output name. A tool that applies without asking will either overwrite one of them or append a counter you did not choose. Seeing that pair side by side before anything is written to disk is how you catch it.
Undo and what happens when it gets one wrong
Some documents will not read cleanly: a faint scan, a handwritten receipt, a statement where the total sits in a column the reader misreads. You flag those, fix the handful by hand, and keep the rest.
Undo matters for the same reason. A rename you can reverse in one step is a rename you can afford to try, and that changes how much checking you feel you need to do before you commit.
Scanned PDFs and the OCR step
If your Cmd+F test came back empty, one step comes before any renaming. OCR reads the pixels and writes a text layer into the file, and only then is there anything for a renamer to extract.
Preview has handled this since macOS Sonoma 14. Open the scan, choose File and then Export, and select Embed Text. Preview recognizes the text and writes it into the PDF. The option appears only when no text has been recognized in the document already, so its presence tells you the file is a scan.
Accuracy tracks scan quality closely. A clean 300 dpi flatbed scan reads almost perfectly. A phone photo shot at an angle in poor light loses digits, and digits are exactly what an invoice number is made of. Check the numeric fields first when you review a batch of scans.
A renamer that runs OCR itself saves you the export step and keeps the whole batch in one pass. What it cannot do is improve the scan. Feed it a bad photograph and you get a bad reading, one more reason to look at the proposed names before they are applied.
FAQ
Can you rename a PDF based on its contents automatically?
Yes, but not with the rename function built into your operating system, because Finder and File Explorer never open the file. You need something that extracts text from the page and maps it into a naming pattern. That is either a script you write yourself or a renamer built for the job.
Does renaming a PDF change its contents?
No. Changing the filename touches the directory entry, not the bytes of the document, so your pages, signatures and form fields stay exactly as they were. The one exception is the Acrobat script route. It saves a new copy rather than renaming, so you finish with two files instead of one.
Can you rename scanned PDFs that have no text?
Only after OCR has run. Until then no text exists in the file for any tool to read, and text-based scripts return empty names across your whole folder of scans. Run OCR first, or pick a renamer that handles it inside the same pass.
How many PDFs can you rename at once?
There is no technical ceiling worth worrying about, and folders of several thousand files process fine. Your real limit is how many proposed names you are willing to check before applying them. Sorting the review list by confidence keeps that manageable at any volume.
Picking the route that fits your folder
Two questions decide it. Do your PDFs carry a text layer, which Cmd+F settles in seconds, and do they share a layout? Same sender and same layout across the folder makes an Acrobat action or a pdftotext script worth the setup hour. A folder from dozens of senders in three languages defeats every anchor you write, because the facts you need are printed on the page and nowhere a pattern can reach. Nymos reads the page instead, proposes a name for each file, and waits for you to approve it: see how it handles a mixed folder.