Why tags beat a deep folder tree
A folder puts a note in one place. That is fine for files, where a document really does live in one directory, and quietly terrible for notes, where the whole value is that an idea shows up again somewhere you did not expect. A meeting note about pricing for a client project is a client note, a pricing note and a Q3 note at once. In a folder tree you pick one and lose the other two, and six months later you are searching for it in the branch you did not pick.
Deep hierarchies fail for a second reason: they force a decision at capture time, which is exactly the moment you know least about what the note is for. You have to know, while typing, which of eleven third-level folders this belongs in. The predictable result is a bloated Inbox folder and a tree that describes what you thought your work was when you built it, not what it is now.
Tags invert both problems. A note can carry three of them, and adding a fourth later costs nothing and moves nothing. The organizing decision becomes reversible, so it can be made badly at first and improved later — which is the only kind of organizing decision most people actually keep making.
None of this makes folders useless. A small number of broad containers — a handful of active areas, an archive — genuinely helps, because it answers "is this live or not". The failure mode is the folder tree that goes five levels deep and tries to encode topic, project, status and date all at once. Use folders for the two or three splits that never change, and tags for everything that does.
Designing a tag vocabulary that survives scale
Good tag vocabularies are small, broad and orthogonal. Small, because a list you cannot hold in your head is a list you will not apply consistently — somewhere between five and fifteen tags covers most personal collections, and past thirty you are effectively writing free text. Broad, because a tag that applies to four notes has no retrieval value; the tag exists to narrow a hundred notes to ten, and a tag that matches everything or almost nothing does neither.
Orthogonal is the one people miss. Tags earn their keep when they are independent axes that combine, not synonyms competing for the same job. Topic, project and status are three axes: #finance + #active + #acme is a query. But #finance, #money, #invoices and #accounting are one axis pretending to be four, and every note tagged with them is a coin flip about which word you used that day. When you draft a vocabulary, look for pairs where you would hesitate about which to apply — that hesitation is the signal that they should be one tag.
Prefer nouns for topics and keep the grammar uniform, because inconsistent forms multiply into near-duplicates (#read, #reading, #to-read). And write the vocabulary down somewhere you see it while tagging. A vocabulary that lives only in your memory drifts within weeks.
Finally, let it change. Split a tag when it grows past the point of being a useful filter, and merge two when you find you have been using them interchangeably. A vocabulary is a working tool that gets maintained, not a taxonomy you get right once.
The over-tagging trap
The classic failure is not too few tags, it is too many. Someone reads about tagging, decides to be thorough, and applies eight tags per note. Every note is now tagged #idea, #work, #important, #2026, #writing, #draft, #followup, #maybe. Nothing is retrievable, because a tag that appears on 90% of notes carries no information — filtering by it returns almost the whole collection, which is where you started.
The second version of the trap is one-off tags. A tag applied to a single note is a note about the note. It felt precise at the time, and it produced a tag list four hundred entries long that nobody will ever scroll. If a distinction only matters for one note, put it in the note's text — full-text search handles it perfectly well.
The useful heuristic is to imagine the query before you apply the tag. If you cannot picture yourself one day asking "show me everything tagged X", the tag is decoration. Tags that survive that test tend to be few and boring, which is the point.
This is also why the tool here proposes a handful of tags rather than a rich set. It would be easy to generate twenty plausible labels per note. It would also make your collection worse.
What zero-shot classification actually does
The model behind this page is a natural language inference model — a classifier trained on one narrow question: given a premise sentence and a hypothesis sentence, does the premise imply the hypothesis, contradict it, or neither. That is all it was taught. It has no notion of tags or notes.
The zero-shot trick is to turn classification into that question. Your note becomes the premise, and each of your candidate tags is written into a template sentence — "This note is about travel." — to become the hypothesis. The model's confidence that the note entails that sentence becomes the tag's score. Do this once per tag and you have scored a note against a label set the model has never seen, which is where the name comes from: no training examples for these classes, zero shots.
The practical consequence is that your label wording is the whole interface. "Money" and "invoices I need to chase" are different hypotheses and give genuinely different results, and phrasing a tag as a short descriptive noun phrase usually beats a single cryptic word. It also means the tags are scored independently rather than competing, so a note can honestly come back as strongly both #work and #travel.
The cost model follows from the same mechanism: one forward pass per note per tag. Ten notes and six tags is sixty passes. That is why this page caps the tag list and the note count, and why adding a tag is more expensive than adding a note.
Where it will be wrong
It reads one note at a time, in isolation, with no memory of the others and no idea what your project names mean. A note that says "ping Dan re: the thing" is not classifiable by any model, and one that says "Orion slipped two weeks" will be tagged on the surface meaning of the words, because nothing here knows Orion is a product. Domain shorthand — the majority of what real notes contain — is the weak spot.
Short notes are also harder than long ones. There is less signal in five words, and the scores get correspondingly less confident, which is why the confidence figure is displayed on every suggestion rather than hidden behind a threshold. Treat anything under about 50% as the model shrugging.
The model at this size is roughly 22 million parameters — small enough to download in seconds and run on a CPU, and nowhere near a frontier model at understanding nuance. That trade is deliberate: a model that runs on your machine can be handed your actual notes, and one that runs on ours cannot without you sending them to us.
And it is a suggester by design, not by disclaimer. Nothing is applied until you click it. A tagging tool that silently applies its guesses produces a collection you cannot trust, which is worse than no tags at all — because now you do not know whether an untagged note is untagged or just misjudged.
Nothing you paste is uploaded
The model files are downloaded to your browser once, cached, and executed on your own hardware through WebAssembly — or your GPU via WebGPU when the browser offers it, purely as a speed-up. Your notes are used as inputs to that local computation and are never sent anywhere. There is no endpoint on this page that accepts your text; you can watch the network panel while it runs and see only the model download.
This matters more for tagging than for most tools, because to tag a collection usefully you have to paste the whole collection — including the notes you would never paste into a web form. The only version of this tool worth building is one where that is safe.
The download is about 87 MB the first time and nothing on later visits. Browser storage is partitioned per site, so the OmniCanvas app keeps its own copy — that is a browser security rule rather than a choice we made.
Getting the result somewhere useful
Once you have accepted the tags you want, the notes can go to a canvas laid out as labelled groups, so the grouping you just approved is visible as space rather than metadata. That is the shape the same organization takes in OmniCanvas: folders and tags on the notes, and a canvas where related work sits together.
If your input is a raw brain dump rather than distinct notes, run it through the [brain dump organizer](/tools/brain-dump-organizer) first to split it into items. If what you want is grouping without deciding on names at all, the [semantic note clusterer](/tools/semantic-note-clusterer) groups by similarity instead of against a vocabulary. And if you are still choosing a system, the [second brain quiz](/tools/second-brain-quiz) is a faster way to decide than reading three more articles about PARA.