A Tag Naming System That Won't Fall Apart as Notes Grow

Tags feel effortless with ten notes. They feel chaotic with a thousand. That's not because tagging is a flawed idea — it's because most people never agree on a naming convention before the collection outgrows the point where ad hoc tags are still legible. Fix that early and a tag list stays useful indefinitely; skip it and every search starts missing notes that should have turned up. If you already use files, projects, and tags together, this is the naming layer that model needs to keep working as it scales.

Quick answer

Pick one delimiter, one singular-or-plural rule, and a short fixed list of prefixes before the tag list grows past twenty or thirty tags. A naming convention does two concrete jobs: it lets you deduce what a tag means from its structure alone, and it guarantees each name stays unique within the collection. Both properties degrade the moment a tag list grows without rules — and retrofitting a convention onto an existing mess takes a lot more work than starting with one.

Step-by-step

The four ways tags fragment as a collection grows

Four patterns account for almost all tag sprawl. All four are avoidable with a rule decided once, up front.

Delimiter drift. A tag usually has to be one continuous string — no spaces — so a multi-word idea needs a hyphen, an underscore, or camelCase to hold together. Some platforms simply don't support multi-word tags at all, which forces awkward concatenations. Without an agreed-on delimiter, #client-work, #clientwork, and #ClientWork end up as three different tags instead of one.

Singular vs. plural. The same topic tagged inconsistently — #note in one place, #notes in another — is one of the most common sources of fragmentation, splitting a single concept across near-identical tags) that don't group together.

Synonyms and near-duplicates. Free-form tagging "lack[s] mechanisms for handling synonyms, acronyms and homonyms" by default. #js, #javascript, and #JS can all describe the same thing, each invisible to a search for the others.

Vague or overloaded tags. A tag that doubles as an unrelated common word, or one too vague to mean anything specific — #stuff, #misc — stops functioning as a filter once the collection has more than a handful of notes in it.

Pick one delimiter and never break it

kebab-case is the easiest default for a personal system. It's readable, it doesn't need escaping inside Markdown, and it matches the slug conventions developers already use everywhere else.

Before:              After:
#ClientWork       →  #client-work
#client_work      →  #client-work
#clientwork       →  #client-work
#Notes             →  #note
#notes             →  #note

Once a tag exists, resist creating a second version of it later — search for it first. It's the same discipline behind keeping Markdown files consistent: one rule, applied every time, beats a good rule applied occasionally.

Use prefixes instead of nested tags for structure

If the app doesn't render true nested or hierarchical tags, a prefix convention fakes the hierarchy inside a flat tag namespace and keeps related tags sorting together alphabetically:

status-draft
status-published
project-website
project-app-launch
topic-markdown

Keep the prefix list short and fixed — decide it once. Prefixes are the one part of a tag system worth planning ahead, because changing one later means renaming every tag that already uses it.

Common problems and fixes

An elaborate tag hierarchy built before there's real content to tag. The fix is restraint: spare the time creating tags before you need them — tags minted ahead of actual notes tend to go stale once real organizational needs turn out different from the plan. Let tags grow out of notes you're actually writing, not a wishlist.

Near-duplicate tags accumulating unnoticed. Before creating a new tag, check whether an existing one already covers the idea. Reusing a tag beats minting a near-duplicate every time — this single habit prevents most of the fragmentation above.

A tag list nobody has looked at in months. A short periodic review is enough — once a quarter, fifteen minutes. Sort tags by how many notes use each one, then merge the lowest-use near-duplicates into whichever tag already has the most notes attached to it. This pairs well with a capture-first note-taking system that deliberately defers organizing until there's enough material to organize sensibly.

Frequently Asked Questions

Should tag names be singular or plural?

Pick one and enforce it everywhere — singular is the more common convention (#project, not #projects) because it reads naturally as a label. The specific choice matters less than never mixing both forms for the same concept, since #note and #notes will search as two separate tags in most systems.

How many tags should one note have?

Two to four is a reasonable ceiling for most notes. A note tagged with a dozen tags usually means the tags are standing in for a summary instead of a category — if you can't describe what a note is about in one short phrase, the fix is usually a better title or a split note, not more tags.

Should I use nested tags like project/website or project-website?

Only if the app actually renders nested tags as a hierarchy — some do, some just treat the slash as a literal character in the tag name. If it doesn't, a flat prefix convention like project-website still gets groupable, sortable tags without depending on a feature that may not exist.

What's the fastest way to fix a tag list that's already a mess?

Don't try to redesign it in one sitting. Pull up every tag, sort by how many notes use each one, and start merging the lowest-use near-duplicates into the tag that already has the most notes. A once-a-quarter fifteen-minute pass keeps a tag list honest without turning it into a project.

Doing this with Carets

Carets organizes notes and code into files, projects, and tags natively, so the naming discipline above applies directly — pick a delimiter and a prefix list once, and every file you tag stays findable as the collection grows. Everything is stored as plain text and Markdown rather than a proprietary format, so your tags and files stay portable no matter how the app itself changes over time. It's native and fast on iPhone, iPad, and Mac, built for writers and developers who want their organizational system to keep working instead of needing a rebuild every few months.

Get Carets on the App Store for iPhone, iPad, and Mac.