Automatically move all folders containing a certain file type using Hazel (Nested Conditions) (Mac)
Based on Productivity Guru's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Hazel can automate folder organization on macOS by watching a folder and applying rules that move matching files in the background.
Briefing
Hazel can automatically sort downloaded font files into a single “fonts” folder—even when fonts arrive inside nested ZIP-extracted folder structures—by using nested conditions that match on file extension and on subfolder depth. The key fix is preventing non-font assets (like a website preview folder) from being moved alongside the fonts, something that becomes tricky because Google Fonts packages often unpack into multiple layers of folders.
The workflow starts with a real-world problem: fonts are commonly delivered as ZIP archives. After unzipping, each font may appear inside its own folder, and the result is a cluttered downloads directory that’s hard to browse when you need a specific typeface. The transcript demonstrates a Hazel setup that watches a target folder and, when rules match, moves matching items into a dedicated fonts directory.
To build the rule, the creator first prepares an example folder containing mixed content: a PDF, HTML/CSS files, and a set of font files (such as Roboto) placed under a “fonts” area. They then create a Hazel rule named “fonts.” Using an Option/Alt-based nested condition, Hazel is configured to look for files (or subfolders) whose extensions match font formats—specifically “.ttf” (and optionally “.otf” via a parallel rule). Matching items are moved into a “fonts” folder.
The crucial complication is that font packages can include extra files and nested directories. When the rule only checks extension, Hazel may also move unrelated content from the example website into the fonts folder. The transcript’s solution is to add a second condition that filters by subfolder depth. By checking that the font file appears at subfolder depth 1 (i.e., the font file sits directly in the expected folder level), Hazel avoids moving files that live deeper in the hierarchy—such as assets inside “layer 1 / layer 2 / layer 3” paths.
The demonstration shows how Hazel’s “previewing” helps validate matches: dropping the Roboto font into the rule’s evaluation reveals whether it lands at the correct depth. After setting the subfolder depth threshold to 1, running the rules moves only the intended font file(s) to the fonts folder, while leaving the example website content behind. The same approach is framed as reusable beyond fonts: nested conditions can sort images, videos, or other file types by combining extension checks with structural rules about where those files appear after extraction.
Overall, the takeaway is practical: for automated organization on macOS with Hazel, extension matching alone often isn’t enough when archives unpack into multi-layer folder trees. Adding a structural constraint like subfolder depth makes the automation reliable and prevents collateral moves.
Cornell Notes
Hazel can automatically move font files into a single “fonts” folder by combining two filters: file extension (e.g., .ttf) and nested folder structure (subfolder depth). The extension rule catches the right file type, but packages extracted from ZIPs often include extra website assets in deeper folders. Adding a subfolder depth condition (font files at depth 1) prevents those unrelated files from being moved. The result is a clean fonts directory where only the actual font files land, even when the source content is messy after unzipping.
Why do font ZIPs create a sorting problem that Hazel needs more than just an extension rule to solve?
How does the nested condition in Hazel help target only font files?
What is the practical purpose of the “subfolder depth” condition?
How does Hazel “previewing” help confirm the rule is matching the right files?
How can the same approach be extended beyond fonts?
Review Questions
- When would an extension-only Hazel rule accidentally move non-font files from a font package?
- What subfolder depth value was used to ensure only the actual font file moved, and why?
- How would you adapt the rule if you needed to capture both .ttf and .otf fonts from the same extracted folder tree?
Key Points
- 1
Hazel can automate folder organization on macOS by watching a folder and applying rules that move matching files in the background.
- 2
Font ZIPs often unpack into nested folder trees, so extension matching alone can move unwanted assets.
- 3
Use Hazel nested conditions to combine an extension filter (e.g., .ttf, optionally .otf) with a structural constraint.
- 4
Set a subfolder depth condition so only font files at the expected folder level (subfolder depth 1 in the demo) are moved.
- 5
Validate rule matches using Hazel’s previewing so you can confirm both extension and subfolder depth before running rules.
- 6
The same extension + subfolder-structure pattern can be applied to other extracted content types like images and videos.