Back to blog

What's New in File Arbor 1.2.0: Content Conditions for PDFs, DOCX, and Text

File Arbor 1.2.0 adds content conditions: match rules to text inside PDFs, DOCX, and plain-text files, not just names. Deterministic, offline, Pro only.

September 6, 2026
File Arbor Team

File Arbor 1.2.0 adds two new rule conditions: content contains and content matches a regex. Rules can now decide where a file goes by reading what's written inside it — a PDF, a Word document, a plain-text file — instead of only its name, extension, size, or date. Both conditions are Pro-only and read the file locally; its text never leaves your machine.

1.3.0 update: This post describes File Arbor 1.2.0. Since 1.3.0, a Pro rule can also read scanned PDFs and photos with OCR, and use values it reads, such as an invoice date, to build the file name and folders. Every plan can rename files, and a move or a rename can be undone from History. The "No OCR" and "No renaming" points below describe 1.2.0; the changelog lists what changed.

Here's exactly what the two conditions do, what they can read, and — just as important — what they can't.

Two New Conditions: Content Contains and Content Matches a Regex

Every File Arbor rule still works the same way: an IF side that decides which files match, and a THEN side that decides what happens to them. 1.1.0 introduced actions for the THEN side — move, Recycle Bin, delete, run a command. 1.2.0 doesn't touch actions; it adds two new options to the IF side, alongside the existing name, extension, size, and date conditions.

Content contains (Pro)

A plain-text search inside the file. It's accent- and case-insensitive, so a search for muller matches a file that actually contains Müller, and cafe matches café. You can list several terms separated by commas, and the condition matches if the file contains any of them — it's an OR, not an AND.

A practical example: routing anything that mentions an invoice or a receipt into one folder, regardless of how the PDF was generated.

  • Watch: Downloads
  • Match: extension is .pdf, content contains invoice, receipt
  • Action: Move to Documents/Invoices

Because the match is case- and accent-insensitive, INVOICE, Invoice, and any accented variant of either word all satisfy the same rule. You don't write multiple conditions to cover capitalization.

Content matches a regex (Pro)

The second condition runs a regular expression against the extracted text. Unlike content contains, it's literal — no accent-folding, no case-insensitivity. What you write is what gets matched, character for character. File Arbor validates every regex against catastrophic backtracking patterns before it lets you save the rule, so a pattern that could hang the matcher is rejected up front rather than discovered later on a real file.

  • Watch: Downloads
  • Match: extension is .txt or .md, content matches a regex \bINV-\d{4,6}\b
  • Action: Move to Documents/Invoices/By-Number

If regular expressions are new to you, our beginner's guide to regex file rules covers the syntax File Arbor supports, independent of whether you're matching a file name or, as here, its content.

What Files Can Content Conditions Actually Read?

Three kinds of files: PDFs that contain a text layer, Word documents (.docx), and plain-text formats — TXT, Markdown, and CSV. File type is detected by looking at the content itself, not by trusting the extension, so a text file with the wrong extension is still read correctly.

Extraction is lazy. File Arbor doesn't open and read every file that arrives in a watched folder — it only extracts text when a rule with a content condition actually needs to test that file. Rules with no content condition behave exactly as they did before 1.2.0, at the same speed.

What Content Conditions Don't Do

This is the part worth reading closely before you build a rule around it.

  • No OCR. A scanned PDF or a photo of a document has no text layer, so there is nothing for a content condition to read. It will not match, no matter what the document says on paper.
  • No spreadsheets (XLSX), no encrypted PDFs, no DOCX headers, footers, or footnotes. Content conditions read the body text of a DOCX and the text layer of an unencrypted PDF — nothing else.
  • No renaming. A content condition decides which folder a file goes to. That's the entire job. There is no naming template, and no mechanism to pull text out of a file and into its file name.
  • Not AI. This is deterministic string and regex matching — the same file produces the same result every time, offline, with no model interpreting or summarizing anything.

None of this is a bug to be patched quietly later — it's the boundary of what the feature is for. If your files are scanned images, or you need automated renaming from content, content conditions are the wrong tool for that job today.

Are There Limits on What Content Conditions Can Process?

Yes, deliberately. File Arbor reads up to 32 MB per file, and within that ceiling it only examines the first 256 KB of extracted text and the first 20 pages of a PDF. Extraction stops after 5 seconds per file regardless of how far it got. A rule tests against whatever text was extracted inside those limits — nothing beyond them.

Whatever text File Arbor pulls out of a file to test a rule is never written to disk and never appears in the app's logs. It lives in memory for the length of that one check and is discarded afterward.

How This Compares to Hazel and File Juggler

Content-based rules are not new to file automation, and File Arbor isn't claiming otherwise. Hazel, the long-standing Mac automator, has had a "Contents contain" condition for years — it's backed by Spotlight and fast, with a slower "Contents contain match" fallback that reads the file directly when Spotlight hasn't indexed it. Hazel 6 went further and added on-the-fly OCR for non-OCR'd files, plus a way to supply passwords for encrypted PDFs. File Arbor does neither of those two things. If your workflow depends on matching scanned documents or reading password-protected PDFs, Hazel currently handles that and File Arbor does not.

File Juggler, the Windows-only automator, has had mature content matching for years too — it reads PDFs, DOCX, and text files, with regex, patterns, and word-list variables it can also use to rename and file documents. That's a more mature implementation in some respects, and File Arbor doesn't have the word-list variable system File Juggler offers. What File Arbor adds isn't a first in the category — it's the same kind of content rule available on both Windows and macOS from one app, matching deterministically and offline, with no Spotlight dependency, at a one-time price with a free tier. See our full File Juggler comparison for the rest of the platform differences.

Pricing and Availability

Both content conditions are part of File Arbor Pro, a one-time $24.99 purchase with no subscription and lifetime updates. The free plan is unchanged: one watched folder, two rules, manual mode. Content conditions, like Auto Mode and subfolder scanning, need Pro. See pricing for the full breakdown.

FAQ

Does File Arbor's content matching work on scanned PDFs or photos of documents?

No. Content conditions read a file's actual text layer, and a scanned PDF or a photographed document has none. File Arbor does not run OCR, so a scanned invoice or a photo of a receipt will never match a content condition. Run it through OCR software first, or match it by name, folder, or date instead. Since 1.3.0, a Pro rule reads scanned PDFs and photos with OCR, on your computer.

Does a content condition rename files based on what's inside them?

No. Content conditions only decide which folder a file moves to. There is no naming template and no way to pull text from inside a file into its file name — the file keeps the name it arrived with. If you need automated renaming, File Arbor's content conditions are not built for that. Since 1.3.0, every plan can rename files, and a Pro rule can put a value it reads from a document, such as an invoice date, into the file name.

Is File Arbor's content matching powered by AI?

No. It's plain-text and regular-expression matching, not a language model. The same file produces the same result every time, the check runs entirely offline, and no AI service ever sees the text. If you want AI-driven file naming or categorization, that's a different kind of tool than File Arbor.

What file types can File Arbor's content conditions read?

PDFs that contain a text layer, Word .docx files, and plain-text formats — TXT, Markdown, and CSV. It cannot read spreadsheets (XLSX), encrypted PDFs, or the headers, footers, and footnotes of a Word document. File type is detected by examining the content itself, not by trusting the file's extension.

Are there size or length limits on File Arbor's content matching?

Yes. File Arbor reads files up to 32 MB, and within that limit it only examines the first 256 KB of extracted text and the first 20 pages of a PDF. Each file gets up to 5 seconds before extraction stops. These caps keep large files from slowing down folder watching.

Is content matching available on File Arbor's free plan?

No. Both content conditions — content contains and content matches a regex — are part of File Arbor Pro, a one-time $24.99 purchase with no subscription. The free plan still covers one watched folder, two rules, and manual mode, but content-based conditions require an upgrade to Pro.

How to Get File Arbor 1.2.0

The app updates itself on Windows and macOS, or grab the installer from the download page. If you're setting up File Arbor for the first time, the getting started guide walks through your first rule, and existing Pro users can add a content condition to any rule from the same editor they already use for name, size, and date conditions — no new interface to learn.