Finder tags alternatives: what you can drop
A tagging scheme usually fails in one of two ways, and the two have nothing in common. In the first, the colors stop being applied. A few hundred files carry them, several thousand do not, and a sidebar click now returns an arbitrary slice of the disk rather than an answer. In the second, the colors were applied faithfully and then vanished somewhere in transit: on a USB stick handed to a colleague, inside an archive, on a drive shared with a Windows machine. Neither failure is fixed by tagging harder. Both become tractable once the feature is taken apart, because a tag is not one feature. It is four jobs wearing the same coat, and three of those jobs have perfectly good homes elsewhere.
What a tag is once the Finder is out of the way
A tag lives in two places at once, and the split explains most of the surprises.
The first place is the file. Tags are written to an extended attribute named com.apple.metadata:_kMDItemUserTags, which holds a binary property list. Read it with xattr -p com.apple.metadata:_kMDItemUserTags file and the contents are a plain array: each entry is a tag name, a newline, and a number that identifies the color. Red carries the number 6. A tag with no color has no number attached. That is the whole of it. The attribute travels with the file, it is not part of the file's contents, and nothing outside macOS knows what it means.
The second place is the Finder's own preference file, which holds the list of tags that exist and the seven that sit in the keyboard slots. Reading FavoriteTagNames out of com.apple.finder returns eight entries: one empty entry followed by the seven default color names. The empty entry at the front corresponds to Control-0, the shortcut that strips every tag from a selection.
Use keyboard shortcuts to tag files quickly: select a file, then use Control-1 through Control-7 to add (or remove) your favorite tags. Control-0 (zero) removes all tags from a file. Source: support.apple.com
There is a third place worth naming, because it causes the strangest symptom. Spotlight keeps its own copy of the tag names in the search index, and that copy holds names only. Running mdls -name kMDItemUserTags on a tagged file returns the names with the color numbers stripped out. So the color a person sees in a list view comes from the Finder matching a name against its palette, not from anything the search index knows.
The four jobs hiding inside one feature
Applying a tag feels like a single action. It is not. Watch what the decision is actually for, and four different intentions separate out.
A state marker. To do, waiting on someone, done. These change often, sometimes several times a day, and their value comes entirely from being current.
A cross folder grouping. One engagement whose files sit in an invoices folder, a footage folder and a downloads folder. This almost never changes after it is set, and its value comes from completeness. A grouping that misses a quarter of the files is worse than no grouping, because it invites the belief that everything is accounted for.
A visual scan aid. A color that makes the right row jump out of a list of two hundred. No machine needs to read this. It only has to survive a glance.
A search entry point. A sidebar item that performs a filter without anyone typing a query. This one depends on an index, and without the index it silently returns nothing.
The four have incompatible requirements. Frequent rewriting versus never rewriting. Human legibility versus machine legibility. Tolerant of gaps versus destroyed by gaps. Most abandoned schemes died because one palette of seven colors was asked to serve all four at once: red meant urgent in January, unreviewed in March, and a client name by June, after which filtering on red returned a pile with three meanings mixed into it.
Where each job goes instead
Sorting the four apart makes the replacements obvious, and it makes clear that there is no single replacement. Each job goes somewhere different.
| Job the tag was doing | Where it goes | What improves | What it costs |
|---|---|---|---|
| State marker | A folder per state, or a prefix in the filename | Survives copying, archiving and other operating systems | One file cannot hold two states at once |
| Cross folder grouping | A saved search (Smart Folder) | Files created later join automatically if they match | Only classifications expressible as conditions |
| Visual scan aid | A sortable prefix in the name | Sorting gathers them; readable anywhere | Slower to spot than a block of color |
| Search entry point | A saved query or a shell alias | Conditions can be far more precise | The query has to be written once |
Moving state markers into folders is the least fashionable option and the most durable one. Three folders called inbox, in progress and done, and the act of moving a file becomes the act of recording its state. Nothing can be forgotten, because a file cannot sit in a folder and not be in it. The filename prefix version achieves the same thing when moving files would break references pointing at them.
Groupings belong in saved searches. The Finder can save a set of search conditions, and the saved result appears in the sidebar alongside the tags it is replacing. Apple documents both the conditions available and the way to save a search as a Smart Folder in Narrow your search results in Finder on Mac and Create or change a Smart Folder on Mac. The structural difference is worth pausing on: a tag applies to the files that were present when someone applied it, while a condition applies to every file that will ever exist.
Search entry points move well to the command line. The Spotlight index is queryable from a terminal, so an alias holding a frequently used filter opens the same result set as a sidebar click, with conditions a sidebar cannot express. The visual scan aid is the one replacement people resist, because a colored row really is faster to spot than a text prefix. The honest answer is that the speed difference is real and small, and it disappears entirely once sorting does the gathering. A leading number or symbol pulls the relevant rows to the top of the list, at which point nothing has to be spotted at all.
One practical note on sequencing. Replacing all four jobs in a single afternoon tends to collapse, because the new scheme has to be invented and applied at the same moment. Moving one job at a time works better, and the state marker is the right one to move first: it is the job with the highest rewrite rate, so the benefit shows up within days rather than months, and folders are the easiest of the replacements to set up.
The one job with no clean replacement
Three of the four move without loss. The fourth does not, and it is the only reason to keep tags at all: putting one file into two classifications without making a second copy of it.
Folders are a tree. A file occupies exactly one node. Putting it in two places means either duplicating it, which produces two files that drift apart until nobody knows which one is current, or creating an alias or symbolic link, which introduces a pointer that can break when the target moves and behaves unpredictably when a sync client tries to reproduce it on another machine. Both options fail quietly rather than loudly, which is the worst way to fail.
Saved searches have a different limit. They can only capture what a condition can express. Extension, modification date, enclosing folder, words inside the document: all straightforward. But a classification like this one is a candidate for the pitch or this needs a second read before it ships exists only in someone's judgement. There is no attribute to match on.
That narrows the honest case for tags to a single sentence. Keep tags for classifications that cross folders and cannot be written as a condition. Everything else moves to names, folders and saved searches. Anyone who reviews their current tags and finds that every one of them could have been a search condition can retire the whole scheme without losing information.
The portability question decides the rest
There is a second axis, independent of how well the scheme is designed: whether the files stay on the Mac.
Extended attributes depend on both the filesystem underneath and every tool the file passes through, and the results are easy to measure rather than guess at. On a Mac running macOS 26, a file carrying a tag attribute keeps it through cp, through ditto, and through the bundled tar. Compressed with the bundled zip and expanded again, the attribute was gone from the extracted file. Filesystems matter in the same way: volumes that cannot store extended attributes make macOS write a companion file alongside each item, which is invisible on the Mac and very visible to anyone opening the same drive on Windows or Linux.
Even when the attribute survives the trip, the meaning does not. Apple's description of the feature sets its boundary plainly: tags work with files stored on the Mac and files kept in iCloud Drive. Nothing in that sentence covers a third party sync client, a network share, or a colleague on another platform. A recipient outside macOS receives a file with an attribute no software on their machine reads.
So the test is short. If a file stays inside one Mac and its iCloud Drive, tags hold. If it goes onto a stick, into an archive bound for someone else, onto a shared volume, or through a sync service that is not iCloud Drive, then whatever the tag was carrying should be carried by the filename instead. Names survive every filesystem, every archive format and every operating system, which is an unglamorous property that turns out to matter more than color.
Keeping whatever survives small enough to use
One more constraint shapes the outcome, and it comes from the keyboard rather than from the disk. There are seven shortcut slots. A tag outside those seven has to be chosen from a menu or typed, which takes long enough that people skip it when they are busy, which is how the gaps start.
That makes seven a realistic ceiling for tags meant to be applied constantly, and it is a useful forcing function. Seven slots cannot hold three separate axes. Pick one axis, give it the slots, and push the other axes to folders and names where there is no such limit. A scheme that fits in the hand gets used. A scheme of thirty tags gets abandoned in week three, and the half applied result is worse than never having started, because nobody can tell an untagged file from an unfinished job.
What to change first
Before replacing any software, write down which of the four jobs each existing tag was doing. Anything that turns out to be a condition moves to a saved search, anything that turns out to be a state moves to a folder or a name prefix, and only genuine cross folder judgement calls stay as tags. If that inventory leaves a short list of naming rules and saved queries to write, a file manager with folders, a terminal and an assistant in one window removes the window switching that rule writing otherwise demands, and Atriens sets out how that arrangement differs from the Finder.
Frequently asked questions
Is there a way to see every tag currently in use before deciding what to keep?
The Finder keeps the full list in its settings, under the Tags section, and that list is the inventory rather than any individual file. Deleting an entry there removes that tag from every file that carried it, all at once, so it is worth reading the list before touching it. For a file by file view, mdls -name kMDItemUserTags prints the tag names attached to a specific item.
Do tags survive if files are moved to a NAS or a shared drive?
It depends on whether the volume can store extended attributes and whether the sharing protocol passes them through. Apple's documentation covers files stored on the Mac and in iCloud Drive, and says nothing about network volumes or third party sync services. The practical approach is to test with one file: copy it across, then check whether the attribute is still readable on the other side before moving thousands of items.
If tags are dropped, what happens to files that are already tagged?
Nothing happens to the files themselves. The attribute stays where it is until something removes it, and it takes no meaningful space. The tags simply stop being maintained, so they slowly become a record of what was true at the time rather than a live classification. Removing them later is a single Finder operation if the clutter becomes distracting.
Are Smart Folders a full replacement for tags?
For any classification that a machine can evaluate, yes, and with an advantage: a saved search keeps matching files created after it was written, while a tag only ever applies to files someone touched. The gap appears with classifications that depend on human judgement, such as marking a document as the version to show a client. No condition captures that, so those are the cases where a tag still earns its place.