Hazel Contents Contain Not Working: Why and How to Fix It
Hazel's Contents Contain reads Spotlight's index, not the file, so it misses files Spotlight hasn't indexed yet. Here's the fix Noodlesoft recommends.
If Hazel's Contents Contain condition isn't working, look at what it actually reads before you look anywhere else: not the file, but Spotlight's index of the file. When Spotlight hasn't indexed something — a new file, a file synced from cloud storage, a folder excluded from search — the condition finds nothing, even though the text is sitting right there in the document. Noodlesoft's own support forum gives the fix directly: switch the rule to Contents Contain Match, which reads the file itself and skips Spotlight entirely. It's slower. Noodlesoft says so plainly. Slower and correct beats fast and wrong.
That fix solves most cases in under a minute. The rest of this article covers why the problem happens, three more things worth checking if switching the condition doesn't fully solve it, and where Hazel's content matching still beats every alternative, File Arbor included.
Why Does Hazel's "Contents Contain" Stop Matching?
Hazel has two separate conditions for checking what's inside a file, and they work in completely different ways. Contents Contain asks Spotlight whether a word appears in a file — it never opens the file itself. Contents Contain Match opens the file and searches the text directly.
That's a reasonable design. Spotlight's index is fast, and most of the time it's accurate. The problem is the gap between "the file exists" and "Spotlight has finished indexing the file." A file dropped into a watched folder a few seconds ago may not be searchable yet. A file synced down from iCloud Drive, Dropbox, or OneDrive can sit un-indexed for minutes, especially mid-download or on a beta-status sync client. A file on an external drive, a network share, or anything covered by macOS's Spotlight Privacy exclusions won't show up in a Spotlight search at all — which means Contents Contain won't see it either, no matter how many times the rule runs.
None of this is a bug in your rule. The rule is checking an index, and the index is the thing that's behind. Hazel runs the rule correctly every time; it just gets a "no" from Spotlight when the honest answer is "not yet."
The Real Fix: Switch to "Contents Contain Match"
Open the rule, find the content condition, and change the pop-up from Contents Contain to Contents Contain Match. That's the entire fix for most people, and it's the one Noodlesoft's forum reaches for whenever someone reports a match failure that turns out to be an indexing gap.
Contents Contain Match doesn't ask Spotlight anything. It opens the file, extracts the text, and searches it the moment the rule runs. There's no index to be behind, no exclusion list to trip over, no waiting for a background process to catch up. The cost is speed — reading a file directly takes longer than checking a lookup table — but for most Downloads-folder or Documents-folder volumes, that difference is not something you'll notice.
If you're maintaining dozens of rules that all use Contents Contain, you don't have to rebuild them from scratch. Open each one, change the single pop-up menu, and save. It's tedious for a large rule library, but it's a mechanical edit, not a redesign.
Three More Checks Before You Rebuild Every Rule
Switching to Contents Contain Match fixes the symptom. If you want to know why Spotlight missed the file in the first place — or if you'd rather keep the faster condition where it's safe to — these three checks cover the rest of the real-world causes.
- Reindex the specific folder. Search for a word from the file using Spotlight or a Finder window. If the file doesn't appear, Spotlight genuinely hasn't indexed it yet. Apple documents a targeted fix: add the folder to the Spotlight Privacy list, wait a few seconds, then remove it again. Spotlight treats the removal as a signal to reindex that folder from scratch, which is faster than reindexing an entire volume.
- Check the Privacy exclusion list itself. Open System Settings → Spotlight → Search Privacy (System Preferences → Spotlight → Privacy on older macOS versions) and confirm the watched folder — and any parent folder, external drive, or network volume it sits on — isn't already excluded. A folder can end up here by accident, especially after restoring from a backup or migrating to a new Mac.
- Confirm the file has a text layer at all. Open the PDF in Preview and try to click-drag across a line of text. If nothing highlights, there's no text layer to search — the document is a scanned image or a photo, and neither Hazel condition will match it without OCR, which is a separate feature covered next.
What Can Hazel 6 Do That File Arbor Can't?
Worth saying plainly, because it's the honest answer: if your files are mostly encrypted PDFs, Hazel is the better tool for this job, and nothing below changes that.
Hazel 6 added on-the-fly text recognition — Noodlesoft's own documentation describes it as OCR that runs "on images (and on PDFs that do not already contain a text layer)" before a rule tries to match them. That means a scanned invoice or a phone photo of a receipt, something with genuinely no extractable text, can still match a Hazel rule. Hazel 6 also added the ability to supply a password for an encrypted PDF, so a locked document doesn't just fail silently.
File Arbor did neither of these before 1.3.0. Since then, a Pro rule set to also read scanned documents runs OCR on scanned PDFs and on JPEG, PNG, and TIFF images, reading the first and last page of each. Password-protected PDFs are still out of reach — there is no password option — and that's a real gap, not a minor footnote. It's the single clearest reason a Mac user with encrypted documents should stay on Hazel rather than switch.
"Contents Contain" vs "Contents Contain Match" at a Glance
| Contents Contain | Contents Contain Match | |
|---|---|---|
| Reads from | Spotlight's index | The file directly |
| Speed | Fast | Slower |
| Needs the file already indexed by Spotlight | Yes | No |
| Affected by Spotlight Privacy exclusions | Yes | No |
| Matches scanned PDFs / images (Hazel 6 OCR) | Yes, once OCR runs | Yes, once OCR runs |
Where File Arbor Fits — and Where It Doesn't
If what actually drew you here is wanting the same kind of content rule without a Spotlight dependency to think about, that's the one place File Arbor sits closest to Contents Contain Match rather than Contents Contain. Its "content contains" condition — a Pro-tier feature — reads a file's text directly — there's no search index in the loop at all, on either operating system it runs on. A rule that matches muller also matches Müller, since the comparison ignores case and accent marks, and it runs the same way on Windows as it does on macOS. It reads PDFs with a text layer, DOCX files, and plain text, and since 1.3.0 scanned PDFs and photos when the rule is set to read them, but the same list of gaps applies as anywhere else content matching comes up: no spreadsheets, no DOCX headers, footers, or footnotes, and no encrypted PDFs.
That last part is the actual difference worth naming. Hazel's content conditions are macOS only. File Arbor's are cross-platform — the same rule, watching a folder, on Windows or Mac, from one app. For a Mac-only workflow, that's not a reason to switch; Hazel already does what you need, and does more of it once encrypted PDFs enter the picture. It only matters if you're also maintaining rules on a Windows machine and want them to match.
It's also worth being precise about what File Arbor's content conditions do: they choose a destination folder, nothing else. Pulling text out of a document into a new file name is a separate Pro feature, added in 1.3.0: you click a value such as an invoice date once on a sample document, and the rule builds the file name and folders from it. Hazel can do that too, with a captured match token. For a broader look at what content-based filing can and can't do across tools, see our guide to sorting files into folders by content.
Which Fix Should You Try First?
"My rule matched yesterday and stopped matching today, same folder, same files." Switch that rule to Contents Contain Match first. This is almost always an indexing gap, and the match variant sidesteps it entirely.
"The file is on OneDrive, Dropbox, or an external drive." Check Spotlight Privacy for that volume before anything else. Cloud-sync clients and external drives are the most common places a folder ends up excluded without anyone doing it on purpose.
"I copy-pasted the text from the PDF myself and it's definitely in there." Rule out the text layer next — Preview's text-selection test takes ten seconds and tells you immediately whether OCR is the actual missing piece.
"I have scanned documents or password-protected PDFs and none of this applies." Stay on Hazel and use its OCR and password options. A Spotlight fix won't get you there, and while File Arbor Pro reads scans since 1.3.0, it can't open password-protected PDFs — this is Hazel's real advantage, and it's not one this article can talk you out of.
"I want the same content rule on a Windows machine too." That's the one case where File Arbor is worth a look — not as a Hazel replacement, but as a way to run an equivalent rule on a second platform Hazel doesn't reach.
Keeping Content Rules Reliable Going Forward
Default to Contents Contain Match for any rule watching a folder that syncs with cloud storage or lives on removable media — the small speed cost is worth never wondering whether Spotlight caught up. Reserve plain Contents Contain for folders on your main internal drive where you've confirmed indexing keeps pace, since it's the faster option when the index is actually current.
Test a new content rule against a file you already know matches before trusting it against new arrivals. A rule that silently does nothing is much harder to notice than a rule that fires when it shouldn't, and content conditions are exactly the kind of rule that fails silently when the underlying text extraction — Spotlight's or a direct read's — comes up empty.
FAQ
Why isn't Hazel's Contents Contain condition matching my files?
Contents Contain searches Spotlight's index, not the file itself. If Spotlight hasn't indexed the file — because it's new, synced from cloud storage, on an external drive, or the folder is excluded in Spotlight Privacy — the condition finds nothing, even when the text is clearly inside the file. Noodlesoft's own forum confirms this is the most common cause.
What's the difference between Contents Contain and Contents Contain Match in Hazel?
Contents Contain checks Spotlight's index and is fast; Contents Contain Match reads the file directly and is slower but doesn't depend on Spotlight at all. Noodlesoft recommends the second option whenever the first one misses a file it should have matched, since a direct read can't be fooled by a stale or incomplete index.
How do I fix Hazel's Contents Contain not working?
Open the rule and change the condition from Contents Contain to Contents Contain Match — this is Noodlesoft's own recommended fix, and it works because the match variant reads the file's text directly instead of relying on Spotlight. If that doesn't help, confirm Spotlight has actually indexed the folder and that the file has a real text layer, not just a scanned image.
Can Hazel read scanned PDFs or photos of documents?
Yes, as of Hazel 6. Noodlesoft added on-the-fly text recognition that runs OCR on images and on PDFs without an existing text layer before matching, plus a rule option to supply a password for encrypted PDFs. Earlier Hazel versions and most rule-based competitors cannot read a file with no text layer at all; File Arbor Pro can since 1.3.0, but it has no password option.
Does File Arbor have the same Spotlight dependency as Hazel?
No. File Arbor's content-matching conditions read a file's text directly, the same way Hazel's Contents Contain Match does, so there's no search index to go stale or exclude a folder from. The trade-off is the same one Hazel accepts for its own direct-read option: reading the file is slower than checking an index, but it never depends on whether Spotlight got to the file first.
Can File Arbor replace Hazel for OCR or encrypted PDFs?
For scans, yes since 1.3.0, though File Arbor Pro reads only the first and last page; for encrypted PDFs, no. It can't open a password-protected PDF, so an encrypted document will never match a content rule in File Arbor. Hazel 6 does both. If your files are mostly encrypted PDFs, Hazel is the better fit; File Arbor's advantage is running the same content rules on Windows and Mac without a Spotlight dependency.
The Takeaway
Hazel's Contents Contain condition isn't broken — it's answering honestly about what Spotlight has indexed, which isn't always the same as what's actually in the file. Switch the rule to Contents Contain Match and the Spotlight gap disappears entirely. If encrypted PDFs are part of your workflow, Hazel 6's password support does something no Spotlight fix and no File Arbor rule currently can.
If you also keep files on Windows and want the same kind of content rule there, File Arbor's free tier is enough to try a rule on your own files before deciding whether it's worth adding alongside Hazel, not instead of it. See pricing for what the Pro tier's content conditions include.