Also found the same thing, only provides a tag-like visual in the property, but obsidian doesn’t actually add the tag to their system
Have just come back to this to fully work it into my vault structure, and have found the same thing. You get tag behaviours in the field itself, but they don’t seem to be tags as far as the rest of the application is concerned. @mdbraber can you confirm if this is fully working for you, or are you seeing the same thing?
Simple feature that was overlooked, should’ve been implemented when properties was implemented IMO, so +1 here.
3 Likes
+1 on this as well. Frontmatter is great for inserting stuff like URLS and summaries but for categorization it’s better for me to just use the best thing about frontmatter (have distinct areas to add distinct categorization properties) but also the best of tags and the tag wrangler plugin which is the ability to view all your meta as a tree in one place and bulk update, chang and merge values if needed!
2 Likes
Completely agree. One of my biggest gripes with switching from subtags to properties (i.e. a text property called “affiliation” rather than a tag #affiliation/group) is that I can’t see the amount of notes with each affiliated group as easily as just looking at tags and seeing I’ve got 15 notes affiliated with a group. It makes querying easier to have it as a property, BUT I regretted changing it from a tag to a property when I realized there was no easy way to see how many notes were affiliated with each group, what the names of the groups were, and easily change them en masse (such as with the tag wrangler plugin). Having multiple tags fields would make this a breeze and it would be WAY easier for me to remember all the tag types I want associated with a note (i.e. what to build in with a template).
Indeed this would be awesome as someone could select a ‘status’ property for status tags and ‘context’ property for context tags, etc. This would let a clear picture in frontmatter that otherwise looks cluttered if all the key information is in a unique ‘tags’ property. At the same time it reduces the need for subtags and the files get more future-proof IMO.
Definitely +1 here!
I need this desperately. Right now I have to give up using properties as my note contents many tags covering different aspects. All tags jammed into one field make me very confused as I don’t know if I miss any important tags.
I have to fall back to use inline regular tags in a table to make them oraginzed by different properties.
This best explains my pain point and use-case as well.
Having separate properties for tags like this gives more clarity and structure to my notes, and the relationships between them.
My first uses would be to reduce the excessive nested tags I have going on.
- status/x —> status property
- type/y —> type property
- area/z —> area property
And there are additional benefits of these properties being tags, compared to properties that is just a text strings.
+1 This would be so useful.
My use case as a writer would be:
- Type (#poem / #story / #lyrics / #journal entry / #idea etc.)
- Status (#weed / #seedling / #budding / #tree / #fruit etc.)
- Topic (#politics / #relational / #abstract / #dreams / #nature etc.)
- Context (London / Spain / #30DayChallenge / #WritingCamp etc.)
Maybe even:
- Brain function (Logic Brain / Artist Brain / Calendar Brain / Tasks Brain)
1 Like
Sorry, this conversation fell of the radar a bit, but it’s working for me using a self-written plugin. You can try the plugin here: GitHub - mdbraber/obsidian-itags. It’s not made for publication yet, so you’ll have to adapt it to your own needs manually. It’s using an undocumented feature to update the metadata cache so things may break in the future! @ShaneNZ
To clarify a bit: I’m using this plugin to prevent sub-tags, e.g. instead of projectA/subprojectA1 I tag my document with subprojectA1 and it automatically updates the itags field with projectA which is also removed if I remove the subprojectA1 tag.
This can obviously be expanded / changed to add more field of type tags to your vault and treat everything in that field as a tag. The trick is that the cache.frontmatter.tags should be kept in sync with those tags so Obsidian will think they are actually tags (although they don’t appear as such in the file)
UPDATE: the functionality to index other fields of type ‘tags’ too is now included (but not extensively tested!)
I still very much need this feature, I’m using in line properties with the dataview :: syntax right now and can’t switch until I have this.
Any updates from Obsidian? I feel like this would be a pretty quick thing to implement given you already have a “Tag” type for the “Tags” reserved property.
2 Likes
Please add the feature! I need it to organize my backlog, it feels awful and counterintuitive without it! 
1 Like
+1 would really like this too!
Hi, are you able to search for the tag like property? im not
1 Like
No, I’m not. I never got.this working reliably, so I’ve given up on it for now. Still want official support though, it would be so useful:)
1 Like
+1 the possibility to have more than one tag property would be really helpful!
1 Like
This worked very well for me!
It didn’t work initially because I tried adding a new property to types.json that I already had in use, so when I put in “tags” into the code it just changed it to “multitext” when I booted up Obsidian.
You have to make sure the property you are making use the tags type is not in use.
1 Like
How this is still not a feature of properties in 2025
1 Like
+1 for this, this would help with sorting my notes out so much !
1 Like