Finder tags not working: what to check, in order

Three unrelated faults get reported with the same sentence: the tags are not working. In the first, the tag is genuinely gone from the file. In the second, the tag is still on the file but searching for it returns nothing. In the third, both the tag and the search are fine and the sidebar simply does not list it. Each one breaks in a different layer, which is why the common first move, rebuilding the Spotlight index, fixes roughly a third of cases and wastes hours on the rest. Separating the symptom takes about thirty seconds and turns the whole thing into two or three commands.

Sort the symptom before touching anything

Open the Get Info window for one affected file and look at the Tags field. That single observation splits the problem.

Symptom A: the field is empty. Whatever was applied is no longer visible on the file. The suspect layer is the file itself.

Symptom B: the field shows a tag, but searching finds nothing. Type the tag name into the Finder search field or click it in the sidebar and no results come back. The suspect layer is the search index.

Symptom C: the field shows a tag, searching finds it, but the sidebar does not list it. Nothing is broken in storage or in search. The suspect layer is display configuration.

The distinction between B and C is worth making carefully, because both look like the tag has disappeared from the interface. Type the tag name into the search field. Results appearing means the index is healthy and the problem is C. No results means B. Skipping this step is what leads people to reinstall things that were never broken.

Symptom A: read what is actually written on the file

The Get Info window shows the Finder's interpretation. Reading the raw state underneath separates a tag that is gone from a tag that is present but not being displayed.

Tags are stored in an extended attribute called com.apple.metadata:_kMDItemUserTags, which sits alongside the file rather than inside its contents. Running xattr -l against the file lists the attributes it carries. If that attribute is absent, the tag really is gone. If it is present while Get Info shows nothing, the fault is in presentation rather than storage, and the checks in the last section apply.

When the attribute is genuinely missing, the next question is what the file passed through. Measured on a Mac running macOS 26, with the same tag applied to identical files and each copy sent down a different route, the results were not uniform.

Route the file took	Tag attribute afterwards
Copied with cp	Survived
Copied with ditto	Survived
Archived and expanded with the bundled tar	Survived
Archived and expanded with the bundled zip	Lost

The common shorthand that compressing a file strips its tags is therefore not quite right. It depends entirely on the tool. This matters in practice because plenty of ordinary routes quietly insert a zip step: mail attachments bundled by the client, downloads packaged by a web service, folders shared as a single archive. A recipient finding no tags on those files is seeing correct behavior, not a fault.

Filesystem support is the other cause. Volumes that cannot store extended attributes make macOS write a companion file next to each item to hold them. The tag stays visible on the Mac, which hides the problem, while anyone opening the same drive on Windows or Linux sees an extra unreadable file beside every real one.

Sync services form a third category, and the documentation draws a narrower boundary than most people assume. Apple describes tags as working for files kept on the Mac and files kept in iCloud Drive. That sentence says nothing about third party sync clients, network shares or collaboration platforms, all of which reconstruct files on the far end according to their own rules. A tag that vanishes after a file round trips through such a service has not been deleted by anything on the Mac. It was simply not part of what the service carried. Testing this takes one file rather than a theory: tag it, let it sync out and back, and read the attribute again.

One more case belongs to symptom A even though it looks like user error. Control-0 removes every tag from the current selection, and it sits directly beside the number keys used to apply favorites. A slipped keystroke across a selected group of files strips all of them at once, with no confirmation and nothing obviously different on screen until someone looks for a specific color. When a whole folder loses its tags simultaneously and no copying or archiving took place, that shortcut is the usual explanation.

Symptom B: check the index, and check the right volume

A tag that exists on the file but returns nothing from search is almost always an index problem. Tag search does not walk the disk. It queries the index Spotlight maintains, and anything missing from that index is invisible to it no matter what the file carries.

Check the file first. Running mdls -name kMDItemUserTags against it prints the tag names the index holds. A result of (null) while xattr shows the attribute present is the exact signature of symptom B.

A measured example makes the mechanism concrete. Two identical files were given the same tag by the same method, one placed in the home folder and one in the temporary files area. The home folder copy returned its tag names from mdls and appeared in search results. The copy in the temporary area returned (null) despite carrying the attribute, and search returned zero results for it. Same machine, same disk, same attribute. The only difference was location, because certain locations are excluded from indexing by default.

Then check the volume, and this is where the most common wrong turn happens. Asking for the status of / alone is misleading on current versions of macOS. On the machine used for these checks, the two relevant lines read:

• / reported indexing disabled
• /System/Volumes/Data reported indexing enabled

Modern macOS splits the system and the user data onto separate volumes, so / reporting disabled is normal rather than a fault. User files live on the data volume, and search works as long as that one is enabled. Anyone who reads the first line, concludes the index is off, and starts a full rebuild will spend hours and arrive at the same symptom.

If the file turns out to sit in an excluded location, no setting change repairs it properly. The fix is to move the working files somewhere indexed, because an excluded folder also hides its contents from full text search, not just from tags.

Timing accounts for a smaller share of symptom B and is worth ruling out before anything drastic. Indexing is asynchronous, so a tag applied seconds ago may not be searchable yet, particularly on a busy machine or immediately after a large copy operation. External drives are the sharper version of this: a volume attached for the first time has to be indexed from scratch, and until that pass completes, tag searches across it return partial results that look like corruption. Checking mdls again a minute later separates a queue from a fault.

Volumes that were never indexed at all are the remaining case. Drives formatted for use with other systems, and volumes explicitly excluded in the privacy settings, hold the attribute perfectly well and contribute nothing to search. The tell is consistent: Get Info shows the color on every file, and every search across that volume comes back empty rather than incomplete. Partial results point at timing, uniformly empty results point at the volume.

Symptom C: nothing is broken, the list is filtered

When search works and the sidebar does not list the tag, both the file and the index are healthy. The tag is simply not selected for display.

The Finder keeps the master list of tags in its settings, with a checkbox per tag controlling sidebar visibility. Tags created on the fly while saving a file often arrive with that checkbox clear.

To change the tags you see in the sidebar, choose Finder > Settings, click Tags, then select the tags you want to show. Source: support.apple.com

The keyboard slots are a separate list that can also drift. Reading FavoriteTagNames from the Finder's preferences returns eight entries: one empty entry followed by the seven default color names. The empty entry at the front corresponds to Control-0, which removes every tag from a selection. When Control plus a number starts applying an unexpected tag, that ordering has been rearranged.

One destructive behavior in the same settings panel deserves a warning. Removing a tag from that list does not remove it from the panel alone. It detaches it from every file that carries it, in one action, across the whole machine. Tidying up a list of tags that look unused has cost people several hundred marks sitting in folders they had forgotten about. Searching for the tag first and noting the result count takes a few seconds and prevents it.

The fault that fits none of the three: two tags wearing one color

Sometimes the file is fine, the index is fine, the sidebar is fine, and the results are still wrong. Filtering on a tag returns half of what it should. That is usually two similar tags coexisting rather than any malfunction.

The index stores tag names only. Reading indexed values back shows the names with the color numbers stripped, so color plays no part in matching. Two tags that both appear red are distinct if their names differ, and two tags with the same name match together even if their colors differ.

This shows up after any change of wording. Pairs like waiting and to review, or done and complete, end up both in circulation, and from then on either filter returns a partial set. It looks like a bug and is correct behavior. Opening the tag list in the Finder's settings and reading it top to bottom exposes the duplicates immediately.

The same thing happens after migrating from another Mac. Tags applied on the old machine arrive attached to the files and merge into the new machine's list. Any difference in wording between the two machines becomes a permanent split unless someone reconciles the list shortly after the migration, while it is still obvious which name belonged to which era.

What to change so it does not recur

Two decisions prevent most repeat occurrences. First, keep working files in locations the index covers, because a tag applied in an excluded folder is invisible to search regardless of settings. Second, do not entrust classifications to extended attributes for any file that will leave the Mac, since the route may or may not carry them. Filenames survive every filesystem and archive format.

Both decisions involve reading a file listing, running a check, and writing down a rule, which normally means moving between three separate applications for every file inspected. Doing that inside one window that holds folders, a terminal and an assistant together removes the switching, and Atriens sets out how that differs from the Finder.