Get AI summaries of any video or article — Sign up free
Automatically move all folders containing a certain file type using Hazel (Nested Conditions) (Mac) thumbnail

Automatically move all folders containing a certain file type using Hazel (Nested Conditions) (Mac)

Productivity Guru·
4 min read

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.

TL;DR

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?

Font packages are usually delivered as ZIP archives. After unzipping, they often produce nested folder structures: the actual font file may sit at a shallow level, while other package contents (like preview website files) can be stored deeper in multiple “layers.” If Hazel only matches on file extension (for example, .ttf), it can still move unrelated files that happen to be within the same watched folder tree. That’s why structural filtering is needed.

How does the nested condition in Hazel help target only font files?

The setup uses Hazel’s nested conditions (created via Option/Alt while adding a rule) so the rule can apply multiple constraints together. One constraint checks for file extensions such as .ttf (and optionally .otf via a separate similar rule). Another constraint then narrows the match to items located at the correct folder level.

What is the practical purpose of the “subfolder depth” condition?

Subfolder depth acts as a structural gate. In the demonstration, the font file (Roboto) is confirmed to be at subfolder depth 1, while the example website content appears at a deeper depth (e.g., depth 3). Setting the rule to require subfolder depth = 1 ensures Hazel moves only the font file(s) and leaves deeper, non-font assets in place.

How does Hazel “previewing” help confirm the rule is matching the right files?

When Hazel is in preview mode, it reports whether the rule matches a dropped file and shows the subfolder depth it detected. By dragging the Roboto font into the preview area, the user can verify it matches and that its subfolder depth is 1. Dropping the example website content shows the rule does not match because its depth is greater than the allowed threshold.

How can the same approach be extended beyond fonts?

The transcript frames the method as general: combine an extension filter with a structural condition like subfolder depth. That pattern can be used to organize images, videos, or other extracted assets where the desired files appear at a predictable folder level after unzipping.

Review Questions

  1. When would an extension-only Hazel rule accidentally move non-font files from a font package?
  2. What subfolder depth value was used to ensure only the actual font file moved, and why?
  3. 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. 1

    Hazel can automate folder organization on macOS by watching a folder and applying rules that move matching files in the background.

  2. 2

    Font ZIPs often unpack into nested folder trees, so extension matching alone can move unwanted assets.

  3. 3

    Use Hazel nested conditions to combine an extension filter (e.g., .ttf, optionally .otf) with a structural constraint.

  4. 4

    Set a subfolder depth condition so only font files at the expected folder level (subfolder depth 1 in the demo) are moved.

  5. 5

    Validate rule matches using Hazel’s previewing so you can confirm both extension and subfolder depth before running rules.

  6. 6

    The same extension + subfolder-structure pattern can be applied to other extracted content types like images and videos.

Highlights

The reliable fix for font sorting is adding a subfolder depth condition, not just checking file extensions.
In the demo, Roboto sits at subfolder depth 1, while the example website content sits deeper (e.g., depth 3), letting Hazel ignore the unwanted files.
Nested conditions let Hazel apply multiple constraints together so only the intended files get moved into the fonts folder.

Topics