PDF Has No Text Layer? How to Tell Before Building a Rule

A PDF has no text layer when the words on the page were never encoded as text — the file holds only an image of them, so there's nothing for a rule, a search box, or Ctrl+F to read. This is the single most common reason a content-matching rule silently does nothing: not a broken rule, but a file with nothing underneath the picture to match. You can find out which kind of PDF you're looking at in under a minute, on Mac or Windows, before you spend any time building a rule around it. This guide covers that check, what to do when a file fails it, and the other formats and limits that cause the same silent non-match even on a normal PDF.

Why Can't My Rule Find Text in a PDF?

A PDF that comes out of Word, Pages, or a modern scanning app carries two things at once: the picture of the page you see, and a hidden layer of actual characters positioned behind it. That hidden layer is the text layer. It's what a PDF reader uses to let you select a sentence, what Ctrl+F searches, and what a content-matching rule reads.

A scanned page or a phone photo of a document has only the picture. Nobody ran text recognition on it, so there are no characters behind the image — just pixels arranged to look like letters. To a human eye, a scanned invoice and a "printed to PDF" invoice can look identical. To software, one has words in it and the other has none. This is exactly what trips people up: the file looks like a normal document, opens fine, prints fine, and still won't match a content rule unless the rule runs OCR first, because there was never any text to match.

This isn't a File Arbor quirk — any tool that reads a file's contents needs a text layer to read, File Juggler and organize included; the ones that handle scans, Hazel 6 and, since 1.3.0, File Arbor Pro, run OCR to create that text first. Noodlesoft's own Hazel support forum has a recurring thread from users whose rules "stopped reading" PDFs; a missing text layer, or a Spotlight index that fell out of sync with it, is the recurring explanation in that thread.

The 60-Second Test: Does This PDF Have a Text Layer?

Before you build any rule around a PDF's contents, open the file and try to read it the way a rule would: by trying to select or search its text. If nothing selects and nothing searches, there's no text layer, and no content rule will match that file unless it runs OCR first — in File Arbor Pro, by setting the rule to also read scanned documents (since 1.3.0).

On Mac

Open the PDF in Preview. Click and drag across a line of visible text. If individual words highlight, the file has a text layer. If nothing highlights no matter where you drag, it doesn't. As a second check, press Command-F and search for a word you can clearly see printed on the page — a real text layer finds it instantly; an image-only PDF finds nothing.

On Windows

Open the PDF in your default reader (Microsoft Edge handles this out of the box on Windows 10 and 11). Click and drag across a line of text, or press Ctrl+A to select everything. A text layer highlights individual words; an image-only page either selects nothing or draws a single box around the whole picture. Press Ctrl+F and search for a word from the page as a second check — same rule as Mac: found means text layer, not found means none.

Run this test on one representative file before you build a rule around a whole folder of them. A single scanned cover page in an otherwise text-based batch will pass; a folder of desk-scanner output usually won't, and it's worth knowing that in advance rather than after a rule quietly does nothing for a week.

Searchable PDF vs. Scanned PDF: Which Tools Actually Run OCR?

A searchable PDF and a scanned PDF can be visually indistinguishable and functionally opposite. The difference is entirely about whether OCR — optical character recognition — ever ran on the file, either at creation (a scanning app that recognizes text as it scans) or afterward (a separate OCR pass on an existing image-only file).

This is where the tools genuinely differ, and it's worth saying plainly rather than as a footnote: Hazel 6 runs on-the-fly text recognition on non-OCR'd PDFs, and it can be given a password to open an encrypted PDF, directly inside the matching step. File Arbor did neither before 1.3.0. Since then, Pro runs OCR too, when a rule is set to also read scanned documents: it reads the first and last page of a scanned PDF or a photo (JPEG, PNG, TIFF), in 9 languages, at about a second per page. There is still no password field, so an encrypted PDF stays unreadable.

If your PDFs are routinely encrypted, Hazel's password option is the practical reason to reach for it over File Arbor — that's true on a Mac even for someone who'd otherwise prefer a cross-platform tool. For scans, both now run OCR inside the rule. File Arbor Pro reads only the first and last page, though, so if the text you need sits deeper in a long scan, running OCR once, ahead of time, on the files that need it still gets a File Arbor content rule to the same result.

What to Do When There's No Text Layer

Failing the 60-second test doesn't mean content matching is off the table for that file — it means you have two honest options, neither of which is "wait and hope."

Run OCR on it. Since 1.3.0, File Arbor Pro can do this inside the rule: set the rule to also read scanned documents, and it reads the first and last page of each scan. The same rule can then name the scan after a date or number it reads, as shown in how to rename PDF files based on their content. Otherwise, a dedicated OCR tool, your scanner's bundled software, or Adobe Acrobat's built-in recognition step can add a real text layer to an image-only PDF. Once that's done, the file passes the same select-and-search test, and a content rule can read it like any other PDF.

Or skip content matching for that file and match on something else. A rule that matches on file name, the folder it landed in, or its date doesn't need to read a single character inside the file. If a client always emails scanned receipts as receipt-scan-*.pdf, a name-based rule solves the problem without OCR at all — sometimes the honest fix is a simpler rule, not a bigger tool.

Other Formats That Won't Match, Even With a Text Layer

A missing text layer isn't the only way a file quietly fails to match. In File Arbor, none of the following will trigger a content condition, regardless of what's inside them:

• XLSX spreadsheets. Content conditions don't read spreadsheet cells at all.
• DOCX headers, footers, and footnotes. Only the main body text of a Word document is checked — a keyword sitting only in a footer or a page header won't match.
• Encrypted or password-protected PDFs. These can't be opened for text extraction without the password, and File Arbor has no field to supply one.

None of this is specific to File Arbor's implementation — it reflects what a rule engine can extract without a password prompt or a spreadsheet parser, not a bug to be patched later.

The Caps That Cause a Silent Non-Match on a Normal PDF

Even a PDF that passes the 60-second test with a real text layer can still fail to match, because content extraction in File Arbor has hard limits: 32 MB per file, the first 256 KB of extracted text, the first 20 pages of a PDF, and a 5-second processing window per file.

The page cap is the one that catches people off guard. A 40-page contract with the word "termination" only on page 25 will not match a rule looking for it — File Arbor never reads past page 20, so as far as the rule is concerned, that word doesn't exist in the file. The same logic applies to the 256 KB text cap on long, text-dense documents: extraction stops there even if the file keeps going. These aren't arbitrary; they exist to keep a single oversized file from stalling every other file waiting behind it in the queue.

Which Fix Should You Use?

"The file won't select or search at all." It's a scan or a photo with no text layer. In File Arbor Pro, set the rule to also read scanned documents (since 1.3.0); otherwise run it through OCR software first, or route it by name, folder, or date instead of content.

"The text selects fine, but the rule still isn't matching." Check whether the matching phrase sits past page 20, the file is over 32 MB, or the match falls after the first 256 KB of extracted text — any one of those caps produces a silent non-match on an otherwise normal PDF.

"The PDF is password-protected." Neither File Arbor nor a plain content rule can open it without the password. On a Mac, Hazel can be given the password directly in the rule. Otherwise, remove the password before automating the file, if you're able to.

"It's a spreadsheet, or the match is in a Word document's header or footer." Content conditions read a DOCX's body text and a PDF's text layer — not spreadsheet cells, and not headers, footers, or footnotes. Match on the file name or folder instead.

"I have hundreds of scanned files and no time to fix them one by one." Let the rule run the OCR: File Arbor Pro does since 1.3.0, on Windows and Mac, and Hazel 6 does on a Mac. With any other tool, batch-OCR them first with dedicated OCR software, then point your rule at the OCR'd output.

FAQ

What does it mean when a PDF has no text layer?

It means the words on the page were never encoded as text, only as an image of them. A PDF built from a scan or a phone photo stores pixels, not characters, so nothing can select, search, or match its text until OCR recognizes it — the page can look identical to a normal PDF while containing zero readable text underneath it.

Why can't my rule find text in a PDF?

Usually because the PDF has no text layer — it's a scan or a phone photo with no characters to read. It can also happen on a normal PDF if the match falls outside a tool's limits, if the PDF is encrypted, or if the file is a format the tool doesn't read for content, like a spreadsheet or a Word document's header.

What's the difference between a searchable PDF and a scanned PDF?

A searchable PDF has an underlying text layer, created when the file is exported from a word processor or produced by OCR, so its words can be selected, searched, and matched by software. A scanned PDF is a picture of a page, usually from a scanner or a phone camera, with no text layer, so none of its words are readable by software until OCR recognizes them.

How do I check if a PDF has a text layer before building a rule?

Open the PDF and try to select a line of text, or search for a word you can see on the page. On Mac, use Preview's selection tool or Command-F; on Windows, use your PDF reader's search or click-drag to select text. If nothing highlights and the search finds nothing, the file has no text layer.

Does File Arbor read scanned PDFs the way Hazel does?

Yes, since 1.3.0, with two differences. File Arbor Pro runs OCR on scanned PDFs and photos when a rule is set to also read scanned documents, but it reads only the first and last page. And unlike Hazel 6, it cannot open a password-protected PDF, so an encrypted PDF still needs to be unlocked before a File Arbor content rule can match it.

Will a content rule match text on page 40 of a PDF?

No. File Arbor only reads the first 20 pages of a PDF, along with the first 256 KB of extracted text, files up to 32 MB, and a 5-second processing window per file. A keyword that only appears on page 40 of a longer document will not match, even though the PDF has a normal text layer.

The Takeaway

A PDF with no text layer isn't a rule you got wrong — it's a file with nothing to read, and the 60-second select-and-search test tells you which kind you're looking at before you waste any setup time. Run OCR on the files that need it — since 1.3.0, a File Arbor Pro rule can do that itself — or route them by name, folder, or date instead. For everything else, check the format and the caps: no XLSX, no DOCX headers or footers, no encrypted PDFs, and nothing past 20 pages, 256 KB, or 32 MB.

This is the same honest limit covered in our guide to sorting files into folders by content — content rules route files by what's actually readable inside them, and nothing is inferred. If your files pass the test, download File Arbor and build the rule; if they don't, set the rule to also read scanned documents (Pro), or fix the file first.