Finder tags seem like a simple way to organize reference images: color-code them, search by tag, and you have a system. In practice, this works for a small collection of a few hundred images. Once your library grows to thousands or tens of thousands, the limitations of Finder tags become the main problem you face. You cannot have more than seven distinct tags, tags can vanish when you copy files, and searching by tag only works if the tag survived the operation that brought the file to your current location.
The ceiling: seven colors, one limitation
macOS stores Finder tags as extended attributes, and the system defines exactly seven tag colors. You can name them—"inspiration," "color study," "composition"—but there are only seven slots. For a small collection organized into a few categories, this works. For a larger collection that needs finer organization, seven slots disappear fast.
Many reference workflows use more than seven categories. A motion designer might tag clips by motion type (smooth, jerky, flowing, mechanical), mood (energetic, calm, dramatic), complexity (simple, medium, complex), and source (film, game, animation). That is twelve categories before you count subcategories. Finder tags cannot hold it.
Once you hit seven, you have to decide which categories matter most and drop the rest. Or you use a numeric code instead of a semantic tag. Or you stop using tags altogether and switch to folder hierarchies. All of them are workarounds for the same problem: the system cannot hold what your library needs.
The fragility: tags that disappear
Finder tags are stored as extended attributes—com.apple.metadata:_kMDItemUserTags—on each file. They live in the file itself, which sounds robust. In practice, they are fragile.
When you copy a file in Finder, the tags usually come with it. But when you use other tools—cp, rsync, git, cloud sync, backup utilities, even some macOS system operations—the tags can be lost. The behavior depends on what tool copies the file and what options it uses.
A photographer indexing images from a camera import folder: the tags on the originals vanish when the camera app or an import tool copies them. A designer moving references to external storage: the tags disappear with the move. A team sharing files over a network: tags are stripped when the files cross the boundary. None of these is a misconfiguration; this is how extended attributes work when the tool doing the copying does not know to preserve them.
~/Pictures/References- Archive
- Active
- Web
- coii-thumbnailswritten by Coii Ref
- coii-proxieswritten by Coii Ref
- coii.dbwritten by Coii Ref
The deeper problem is that you often do not notice until later. You organize references with tags, move them to archive, back them up, and weeks later discover that the tags are gone. By then, the work is lost.
Why tags do not search reliably
In theory, you can search Finder tags with Spotlight. In practice, Spotlight only finds files whose tags survived the operation that put them where they are now.
If you have archived references with tags, backed them up to another drive, and then search the backup by tag, Spotlight may find nothing—not because the backup went wrong, but because the backup tool stripped the extended attributes. You believe the backup succeeded, but your tags did not make the trip.
This is not a Spotlight limitation; it is a consequence of the underlying fragility. Tags are search-untrustworthy because they are not reliably present.
The reference library problem this creates
For a working library—references you open every week—this might not matter much. For an archive, or a library that spans multiple Macs, cloud storage, or external drives, Finder tags become a liability.
You start by tagging carefully. "This is a lighting study." "This is a pose reference." "This is composition." The tags help you find what you need. Then you back up the library. Move it to new storage. Reorganize the folder structure. Each operation risks losing tags, and you have no way to know whether they survived until you search and find nothing.
Once this happens once, the trust is broken. Your tagging system does not actually work. You have to start over.
When tags work in Finder
Finder tags are reliable for small libraries that live in one place and never move.
If you have a folder of a few hundred reference images on your Mac's internal drive, and you never copy or back up the folder, and you never reorganize it, and you use Finder to manage it, tags work fine. The ceiling of seven categories might even be enough.
But if you have a library that grows, that moves between Macs or drives, that gets backed up, or that is reorganized more than once, Finder tags become a constant source of data loss. The system cannot guarantee they survive the operations a real library goes through.
The alternative: database tags that travel with metadata
Coii Ref stores tags in its own database, which travels with your workspace folder. When you back up the folder, the tags come with it. When you move the folder to another Mac, the tags are intact. When you reorganize the folder structure, the tags stay on the files because they are stored in a .coii-canvas file you control, not in system metadata another tool can strip.
The trade-off is that Coii Ref's tags are not visible in Finder or Spotlight. You cannot open a file in another app and see "this is a pose reference" because the metadata lives in Coii Ref's database, not on the file. But the benefit is that your tags never vanish, and your organizational system survives every operation your library goes through.
If you have spent years organizing references in Finder tags and the tags have never been lost, stay in that system—it works for your workflow. But if you have experienced tag loss, or if your library is growing large enough that seven categories is not enough, the problem is not misconfiguration. It is the ceiling of the system itself.
The practical question
Before you switch away from Finder tags:
Are you hitting the seven-tag limit? If you use three tags consistently and the library is small, Finder tags are fine. If you use more than seven categories, or if your library is large enough that organization matters every day, you have hit the ceiling.
Have you lost tags in a backup or move? If tags have disappeared when you reorganized, copied to another drive, or backed up the library, the fragility is not theoretical. It is a real problem in your workflow.
Do you trust the tag system to hold a year from now? If you organize carefully but worry that a move, a backup, or a tool change will lose them, that hesitation is a signal that the system is not working for you.
If any of these is true, the problem is not something you are doing wrong. It is that Finder tags were designed for quick, small-scale organization, not for a library that grows and moves. At that point, a system that stores metadata in files you control—not in extended attributes another tool can strip—becomes the only reliable way to organize at scale.
For the full landscape of reference organization options, read tags vs folders for images for a comparison, or how to organize reference images on Mac for practical steps. If you are comparing systems, the best reference apps that don't copy your files covers options, and does Eagle copy your files addresses one competitor's approach to metadata. Explore how to build a reference library from existing folders to migrate a tagged collection, or how-to-organize-references-by-project for project-based workflows. If you want to keep metadata portable, what is a sidecar file explains how Coii Ref keeps tags in files you control. The 30-day trial comes with every feature and no card.
The cost of reorganization at scale
Every reference library eventually needs reorganization. Tags fail you the moment that happens. A folder-based system survives it because the folder names travel with the files, and tags in files you control survive operations that strip extended attributes. Finder tags survive none of it.
If your library has never been moved between Macs, never been backed up to new storage, never been reorganized after the initial setup, Finder tags may have never failed you. The question is not whether they will—it is when. The larger the library, the sooner the "when" arrives.
A library of five thousand images that gets backed up monthly, indexed on a second Mac for safety, and reorganized twice a year will lose tags in one of those operations. The math is not in your favour. The system was not designed for a library that moves; it was designed for a library that sits still.
The moment you decide to migrate a large library to better storage, upgrade an aging Mac, or bring your references to a second computer for redundancy, Finder tags become a problem. Coii Ref tags make those operations safe because the metadata travels with the files, encrypted in a .coii-canvas file you can see and version-control.
Seven tags is not enough
The colour ceiling is real, and it matters more than it sounds. A designer working on client projects might tag by client, project phase, status, and asset type. A motion director tags by motion type, tempo, mood, source, and use case. An illustrator tags by subject, style, mood, technique, and licensing status. Every profession hits seven before reaching twenty.
Once you accept the seven-tag limit, you start compromising. You create vague categories like "reference" and "archive" because specific ones ran out. You reuse colours for different meanings in different projects, hoping you remember what you meant. You abandon tagging entirely for some aspects because you ran out of slots.
None of this is your fault. It is the constraint forcing the compromise. A system with unlimited tags would not solve the other problems—disappearing tags, search failures, fragility across backups. But even if those were fixed, the ceiling would still be there, and it would still limit what you can organize.
Finder tags are fine for a quick organizational layer on a small, stable library. For a growing collection you care about, they are a trap that eventually bites.
The choice between Finder tags and a proper system is a choice between temporary convenience and long-term reliability. Finder tags are convenient until they are not. The moment your collection matters—when it represents years of work or thousands of images you do not want to lose—the convenience stops mattering. Only reliability matters. Only a system that keeps your organization intact through moves, backups, and reorganizations delivers that reliability.
For most reference managers that store metadata in files, that means a database. For Coii Ref, it means storing tags in a .coii-canvas file you own, can version, and can move with your library without losing a single tag. The tags survive every operation your library goes through.