Tags, Fields, and when to use one over the other?

While reworking my own tiddlywiki for the umpteenth time, I began to experiment with new ways of sorting my tiddlers using custom fields, (such as the methods discussed Here) and began to wonder, “What is the intended use-case for tags and fields, and how do others use them?”

So that’s what I intend to ask here, for anyone interested in answering.

When do you think you should use one over the other?

How do you use tags, and how do you use fields?

TLDR; It depends but tags are a good start :wink:

IMO it really depends on the usecase. For example, if I create a plugin I try to use fields and prefixes for plugin internal sorting or filtering functions, since they are hidden from the end-user.

For user facing possibilities I do recommend tags, since they may already be known and they have number 1 support in the TW UI and documentation.

I also think it depends a bit on user preferences and experience over time. … I often start with tags for my own stuff. …

After some time I find out, that some of my tags cause “noise” and they should better be hidden. So I need to iterate the whole thing and use fields instead. …

Sometimes it turns out, that initial tag-names are wrong. So renaming them is needed. If so the relink-plugin is your friend.

I think there is no “silver bullet” it really depends, but tags are always a good start, because they are easier to use


Do you ever run into the problem of a tag having the name of a tiddler that you want to use for other purposes?

Ah, yea- I take it you prefix them with $:/ ?
I’m always hesitant to do that incase I somehow mess up the load order of things haha

I can agree with that, I used pretty much all tags until testing the capabilities of fields.

I try to avoid using tags that reference tiddlers. It does mean I don’t use them, I try to avoid it. I prefer to use fields for this… even when the list might be a list of one. Using a tag prevents me from expanding.

I use tags to define the entity of Tiddler. A person tiddler is tagged with “person”. I sometimes use tags for data. But I sometimes regret that decision.

I use tags to further define an entity. I tag a place Tiddler with “place”, and then the type of place. Examples: state county country.

When using tags, as in the examples above, I use all lowercase, because usually Tiddler references are camel case.

that’s an interesting approach, I actually did something a bit similar with some of my older TW

Do you ever create the tag tiddler and have it populate with all the tiddlers categorized with it?

I used to do this with the <<list-links>> macro when creating lists of characters for projects.

Tags, fields, data tiddlers.

I often tend to find myself preferring data tiddlers.

In some situations, I do prefer fields. For certain things, I really like tags.

I haven’t thought about the when’s and the why’s. It is just an automatic thing depending on what types of things I plan to do. And everything seems to be unique enough that I often don’t make a decision based on what I’ve done before.

I did want to mention that I fairly often purposely create tiddlers for my tags. A tiddler for a tag is documentation about that tag, a place for me to report on all tiddlers that are related to that tag. My dashboard for that tag.

Not necessarily. If they are prefixed with $:/ it means they are “system” … They will be hidden in the sidebar and search results, but they are still visible in the tiddler tags area.

For content I don’t use the $ystem prefix. I’m not a big fan of hidden information. Most of my tag-tiddlers contain <<list-links "[tag<currentTiddler>]">> in some way. I think that’s very handy.

Not really. I do have my own tiddler naming system, that fits my personal preferences.

The following info reflects my personal preferences that may not work for everyone.

My tiddler names are usually all-lower-case and words separated with hyphens for readability. So I never need to remember, how I did write a tiddler title. URL-permalinks are always human readable.

Tags are usually single words like task, todo, @work or aReadableTagName
So they shouldn’t clash either.

I do not use tiddler titles as headings. I use proper headings within my tiddler text content. So the tiddler title doesn’t matter too much. It’s more like an ID. I have my own very opinionated theme which fits my needs.

For links I use aliases. My uni-links plugin can handle them. Aliases avoid the tiddler renaming problem for links, since 1 tiddler can have several [[aliases|?]]. [[Aliases|?]] are not case sensitive, so the 2 alias-links shown will actually link to the same tiddler. Alias links can show any other field as a link-text [[alias|?my-field]]

Most of my tiddlers do have a subtitle field, which can be used for lists, where a longer subtitle is needed. (plugin not published)

Tiddlers that are shown in tabs do have a caption field, which is usually only 1 or 2 words, to keep the tab short.

Some of my tiddlers do have a teaser or summary field. Where the teaser is meant to be like a sales pitch and “summary” usually contains an executive summary

Sometimes there is just a short description field … So I’m not settled with those field types yet. To search those fields I use my field-search plugin.

To create multi-line field content I use the field-editor and the field-visibility plugin. The problem with those 2 is, that they “kind of” hide content in edit mode, which I’m not a fan of. (so there is room for improvement)

My tag-dropdowns and my tag-pills have a completely custom handling, which is shown with the slant-01 theme.

All the stuff can be found at: https://wikilabs.github.io/

Warning: There is a problem if someone installs all those plugins at once. – I did develop my personal style over several years and I only add stuff that I really need.
Not all of my wikis use all of the plugins.

I start with a few of them and then start adding them, when using the plugins actually saves time.


Personally, I use tags when I want to links tiddlers with idea/common themes, and fields when I need to store data in a tiddler. If I think that it’s important to see then it go in tags, otherwise I put it in the fields.

If you need to get a list of tiddler in a certain order, tags are easier to work with thanks to the tag dropdown (but custom solutions can be done with the list-links-draggable Macro for example).

I also like to use my fields to trigger custom templates, e.g a description field will display a textarea to write a description, a source field will display a list of sources in a summary element, etc. Previously I used tags for that too but they clutter the UI, IMO tags should be used to inform the reader on what contains the tiddler and it’s relationship to others.

System tags are a special case and are useful to easily see a list of tiddlers with a common purpose.

See Demos — Q&A and tools for tiddlywiki for some examples of tools using the fields of a tiddler (redirect, description, sources, caption instead of title)


I assume your question is related to TiddlyWiki and so I say

  • Tags are absolutely easier to use in TiddlyWiki
    • They are visible to end users
    • They support colors and icons, and this is great from pedagogical point of view
    • They can show quickly what else has been tagged with a specific tag
    • They support drag and drop as a container (all tiddlers tagged with…)
    • They can be exported with a single click
    • and …

So working with tags as a way to categorize things is very easy in TiddlyWiki and I highly recommend using tags.

BUT: Most people do not know when to use tags. They create a noisy, difficult to use, hard to search TW by using too many tags, …

Regarding using fields for categorizing contents: I agree with most of above replies. I also like the The Difference Between Good and Bad Tags • Zettelkasten Method.

Side note: TW-Scripts uses kookma solution plugin (developed 2018) it allows using keywords field like tags. So, you can have two levels of categorizing contents.