Hazel, the Mac app that files things while you keep working

The Downloads folder has four hundred items in it. The desktop is a wall of screenshots. Cleaning it by hand takes half an hour, and a week later it looks the same. Anyone searching for the Hazel app for Mac has already worked out that the problem is not tidiness but repetition, and is now deciding whether a rule engine is worth installing and paying for. The answer depends on one thing: how much of the filing can be described in words before it happens. That line is where automatic filing succeeds and where it quietly fails.

What Hazel actually does

Hazel is a macOS utility from Noodlesoft that watches folders and acts on what appears in them. The mechanism is narrow on purpose. A folder is added to a watch list, conditions are written against the files that land there, and actions run when a file matches. The vendor describes matching on name, date, type, and what site a file came from, among other attributes.

That last condition is worth pausing on, because it is the one that surprises people. macOS records where a downloaded file originated, so a rule can route invoices from one supplier's portal without reading the filename at all. The flip side is that files arriving by AirDrop, or generated by a script in the terminal, carry no such origin. Conditions can only use attributes the file already has, which means the design of a rule starts with an inventory of what is knowable about the file, not with what would be convenient.

Actions go further than moving things. Noodlesoft lists opening, archiving, tagging, and uploading, along with renaming and sorting into subfolders based on name, date, or a combination of attributes. Pattern matching feeds those actions, so a filename can be taken apart and reassembled. There are hooks into Shortcuts, AppleScript, and Automator, which means a rule can hand off to something else entirely once it has identified a file. Spotlight integration, importing into Photos, Music, and TV, notifications, and tag support round out what the vendor calls deep support for macOS technologies.

Put plainly: Hazel is a trigger and a condition and an action, running quietly, forever. Everything interesting about it happens in the condition.

One consequence of that design is worth stating before any rule gets written. The app is a scheduler for decisions that have already been made, not a place to make them. It does not look at a folder and propose an arrangement; it executes the arrangement it was handed. That is why the hard work of adopting it is not learning the interface, which takes an afternoon, but deciding what the folders are for. A Downloads folder that receives invoices, client deliverables, software installers, and screenshots has four jobs in one place, and no rule engine can separate them until a person has said which is which. Teams that get value out of this kind of tool usually redesign the folder structure first and write rules second. Doing it the other way round produces rules that fight each other, because they are all trying to describe the same undifferentiated pile.

What a license costs and what it covers

Pricing is published on the vendor's store page, in US dollars, as a one time purchase rather than a subscription.

License	Price	Covers
Hazel 6	$42	A single license
Hazel 6 Family Pack	$65	Up to 5 members of one household
Hazel 6 Upgrade	$20	Moving up from a previous version

Two details in that table matter more than the numbers. The Family Pack is explicitly limited to private households, so it is not a cheap route to covering a small office. And the upgrade price exists because major versions are paid events. A one time purchase does not mean one payment forever; it means no payment until the next major version, at which point $20 is the published figure. For a utility that runs every day for years, that structure is usually cheaper than a monthly fee, but the arithmetic is worth doing against however long a version tends to last.

A free trial is offered alongside the purchase, which matters because the only useful test of a rule engine is on real folders with real mess in them. Volume pricing is handled by contacting the vendor rather than by a published tier. Support runs through a user guide, a public forum, and a contact form, and the app has been shipping for twenty years as of September 2026. For software that sits in the background touching files, that track record is part of what is being bought.

Where rules break, and how to build one that does not

Building a rule takes about two minutes. Getting it to fire on the right files takes longer, and the failure is almost always in the condition rather than the action.

Three habits prevent most of the frustration. First, add conditions one at a time. Three stacked conditions that produce nothing give no information about which one is wrong; one condition that produces too much at least tells the truth. Second, never make the first action destructive. Set the action to add a tag or change a color label, watch which files get marked over a day of normal work, and only then change the action to move or delete. Third, keep the watched folder shallow. Watching an entire Documents tree will eventually catch something that was never meant to be touched.

Two specific traps deserve naming. Dates are the first. Created date and modified date produce different results, and a downloaded PDF often arrives with an old creation date baked in, so a condition like "created within the last week" silently skips it. The second is rule order inside one folder. If an earlier rule moves a file out, a later rule in the same folder never sees it. Any folder that both sorts incoming files and cleans up old ones needs its rule order decided deliberately, not left to whatever order they happened to be created in.

Beyond filing: the trash and the leftovers

The less discussed half of the app is disposal. Noodlesoft describes keeping the trash in check by deleting files that are too old and clearing things out when the trash grows too large. This is unglamorous and it works, because the failure mode it fixes is forgetting rather than deciding. Disk space comes back on its own.

The other piece is App Sweep. When an application is thrown away, Hazel detects it, searches for the support files that application left behind, and offers to throw those away as well. Anyone who has run the same Mac for five years has a Library folder full of preferences and caches belonging to software that is long gone. Catching them at the moment of deletion is more reliable than trying to identify them months later, when nothing indicates what they belonged to.

There is a condition on trusting any of this, and it is the same condition that applies to every automation: something has to be recoverable. Support files occasionally hold settings worth keeping, such as a license record or a long accumulated configuration. A Time Machine backup or a copy of the folder before the rule runs turns a wrong guess into an inconvenience instead of a loss. Automation raises the cost of a mistake because it repeats, so the backup comes first and the rule comes second.

Rules and judgment are two different jobs

Over the past two years, tools that read a file and decide where it belongs have become common, and the framing is often rules versus AI. That framing hides the useful question, which is whether a given filing decision can be written down in advance.

Conditions that can be written down should be. "Extension is png, name begins with Screenshot, move to a folder named by date" is fully specifiable. Anything fully specifiable runs instantly, costs nothing per file, produces the same result every time, and works with no network connection. A rule engine is the right tool for that work and will stay the right tool.

Conditions that cannot be written down need something that reads the content. Which client a contract belongs to is not recoverable from scan_0043.pdf. No pattern match will find it, because the information is not in the name or the metadata; it is on page one. That job needs a tool that opens the file, and it comes with different properties: slower, metered, and not perfectly repeatable.

	Written as a rule	Decided by reading
Works when the answer is	in the name, date, type, or origin	in the contents
Speed per file	immediate	seconds
Repeatability	identical every time	close, not guaranteed
Needs a network	no	usually

The practical arrangement is to write down everything that can be written down, and to route only the remainder to something that reads. Drawing that boundary once is more valuable than replacing either tool with the other.

The problem that appears at rule number twenty

A few months in, a different problem arrives. With twenty or thirty rules running, the question stops being "how do these work" and becomes "why is this file here". Conditions written in March are not remembered in September, even by the person who wrote them.

Two habits help. Name rules by what they do rather than by their subject, so a list reads as behavior: "move invoices to the client folder" instead of "invoices". And keep logging switched on, so there is a record of what moved where and when. Without that record, an unexpected result has no starting point for investigation.

Then the real friction shows up, and it is not about Hazel at all. Checking a rule means looking at three places: the rule list inside the app, the destination in a file manager, and the file itself from a terminal to confirm timestamps and sizes. Three windows, one file, and a train of thought that breaks every time attention moves. This is the point where automation has been added and the total number of steps has gone up, which is the opposite of the reason it was installed.

Consolidating those three views is a separate decision from the filing engine, and it is worth making on purpose. A file manager with a built in terminal removes the switching cost: the destination folder stays open on the left while a command runs in the same window and the output is read in place. The rule engine keeps filing; the checking stops costing anything.

What to change first

Pick one folder, write one rule, and make its only action a tag. Watch it for a day before changing the action to move, and decide at the same time where the results will be checked, because a filing rule that cannot be verified quickly is a rule nobody trusts. If that checking currently means three windows, Atriens puts the folder, the terminal, and an assistant in one of them, and the comparison page covers how that differs from running two apps side by side.