A Guide On Links vs. Tags In Obsidian

The question “should I use tags or links” is asked regularly in the Obsidian discord.

The prevailing answer seems to be “Well, it depends on what you want to do” or “There’s no correct answer”. Of course, this being the community it is, those are usually followed by helpful people digging into the specifics of the situation. But also, sometimes, the questioner just disappears, and I find myself wondering if they’ve given up over what might well appear to be a non-answer.

Either way, it seems to me like it might be beneficial for us to have a standard response to this question, so I’ve tried to build one. However, I hope this document will continue to be updated (here or elsewhere) with the input of the whole community, so if I have missed relevant [factual] differences between links and tags (or made other errors), please call them out in the thread so I can update this!

Should I Use Tags Or Links?

Hello! Wondering about the nature of tags or links in Obsidian is very common!

The reality is, there isn’t one single answer to this question, but this article is intended to help you understand why one or the other might be better for your situation. We will lay out the facts regarding how tags and links work, so you can make the decision that suits you best.

Tags and Links Aren’t Actually That Different

In Obsidian, tags are actually a kind of link!

What Obsidian calls a link can be defined as: “A connection from one note to another note”.

In Obsidian, a tag is: “A connection from a note to an idea”.

Every note in your vault is a “node”, as you see when you open the graph view. Every tag is also a node, just with no file behind it! You can see this within the graph view by turning on “Tags” under the “Filters” option!

This means a few things:

  1. You don’t actually have to choose between tags and links for organization! They’re complimentary, and we’ll go over why in the next sections.
  2. You can’t go very wrong in whichever path you choose. The two ideas are so similar that there is almost always a way to make tags or links work mostly like the other. In other words: you can achieve nearly all the same functionality with either tags or links… the differences are almost entirely a matter of convenience!

Tags and Links Aren’t Equal, Either

But tags and links aren’t exactly the same, either, and those matters of convenience can become significant over time. Here is a list of factual differences between the two:

Links auto-refactor by default, and tags do not

This is a big one!

When you change the name of a file within Obsidian, all links to that folder will automatically change to be pointing to the right place.

Changing tag names through the entire vault requires the help of a plugin (such as GitHub - pjeby/tag-wrangler: Rename, merge, toggle, and search tags from the Obsidian tag pane), or a risky find-and-replace procedure.

Click behavior is very different for tags and links

Clicking on a tag will open a search for all files that contain that tag.

Clicking on a link will either:

  • Open the file the link is pointing to.
  • Create the file the link is pointing to, if it does not already exist.

Tags are implicitly counters

Instances of each tag are automatically counted up by the Obsidian tag pane! This means that ever tag automatically is also a visual counter of how often that tag appears in your vault.

Tags can be hierarchical

#level 1/level 2/level 3 is a valid tag!

Tags are effectively a “virtual file system”, meaning they can be organized into a tree just like folders, except without the rigid properties of on-disk folders.

Links can have aliases

A link can have multiple “names”, in the format of [[A Note Name|An Alias To The Note Name]]. This can be handy, and is not something tags can do.

Tags can be defined in front-matter

Tags can be defined at the top of a note, something like:

tags: [writing/blog, ideas, blog/status/draft]

This can be a useful way of adding organization to a note in an invisible way. While links must always be written out in text, front-matter can be hidden in Obsidian.

Introduction To “Higher-Order Notes”

If you want to organize using links, then eventually you are going to encounter the idea of a “higher-order note”.

You might have heard the term “MoC” used around the Obsidian community. This stands for “map of content”, and they are a kind of “higher-order notes”. A higher-order note is any note that exists to help you navigate to other notes. The naming isn’t 100% agreed on, so don’t let that confuse you. “Indexes”, “MoCs”, “Higher-Order Notes”… They’re all pretty similar.

What problem do these solve?

HONs solve the problem of navigation between groups of notes without the necessity of using tags. A HON fulfills the same function as a tag: A connection from a file to an idea. A HON is what would happen if, when you clicked on a tag, a note opened representing that tag.

HONs are objectively more functional than tags, as they have all the power of a note, including the ability to have their own tags, but that doesn’t mean they are necessarily “better”.

HON Potential Benefits


  • Can easily show different “lenses” of data, with the same links displayed in different orders. (Within an “animals” HON you might have “Animals that lay eggs” right alongside a list of “Animals that give live birth”).
  • Benefit from the auto-refactoring nature of links. Any change to a note’s name will automatically update the links.
    • (Author’s note: This is particularly beneficial when a group of data is not well understood yet, as note names are more likely to change in this period.)
  • Can easily contain notes, explaining why the links are the way they are, as opposed to tags which are fully static.

HON Potential Downsides


  • Is more complex than a tag, which might require additional, unnecessary maintenance.
  • Has no clear, obvious pattern of construction. Its structure is entirely a matter of convention.
  • Must be backed by an actual file on the file system.
  • Does not automatically get a counter of any kind.


I hope this article has given you a good, basic understanding of how tags and links fundamentally work within Obsidian. There is no reason you need to choose just one or the other! You can mix and match easily, using the unique features of each to benefit your desired workflows.

I also help it gives you a little bit more of a sense of peace going into starting your Obsidian journey, knowing that this isn’t a “choose the wrong path and screw everything up” kind of choice. It’ll be fine, no matter what!

Good luck, and have fun making your notes awesome!


I like this a lot, and I think it’s a good breakdown, but I think it is missing a common use of tags, which is to use them to indicate status or classification. Obviously this goes outside the realm of organizing ideas, but it is another use for tags, so I think you may want to consider referencing it. Here’s what I’ve written about it for more context: Use Obsidian tags as temporal classifiers - Obsidian Publish


Good read! So far, I’ve been thinking of links and tags based on their initial purpose:

  • A link points/directs the reader to another file.
  • A tag marks a note (if it’s in the metadata) or a part of a note. This helps with search filters and general grouping.

Also, since tags also use the search bar, they can be starred!

For the part about “does not automatically get a counter of any kind”, do the counters on Backlinks and Outgoing links panes not count? Or, are you referring to something like what the Block Reference Counter plugin does?


Might be good to discuss graph view further. If you want to use tags in graph view to identify emergent concepts (when enough notes share a #tag, the node gets real big in graph view), then that’s super useful, but it doesn’t really work if you also use tags for status or type (book, person, etc.).

Also, if you want to enable quick way to filter search results, tags are great as search filters.


You use the word risky in describing the possibility to find-and-replace. And although a word of caution is in place I think the word risky is rather strong.

As this article is meant for beginners that try to understand the difference between tags and links the use of “risky” might steer them away for good from find-and-replace actions. Which btw I have found to be very valuable at times. Specially when your fault grows large when manual maintenance is almost impossible.

But I am not a native english speaker so the word risky might sound a bit stronger to my ears then it actually is.

1 Like

I find the term risky well-chosen.
Using a text based search and replace routine, the unwary user might encounter several kinds of problems, such as:

  • Changing the term in the text body instead of the front matter only
  • Changing longer words containing the term (both in front matter and text body)
  • Failing to find all instances of the term because there are six different ways to define tags in the front matter

The difficulties are compounded by there being no easy way to check what you’ve done.

Using VSC, it is shown beforehand what is found and what will change. You can then manually run through those instances to assure that it is exactly what you want and then bulk change them.

But I have no strong feelings about risky other then mentioned in my initial reply :wink: … So risky it is.

I was thinking of “A counter of where this concept occurs across the whole vault”, a la tags… But I went too far saying “of any kind”. You’re right, notes do get backlink and outgoing link counters, which would be kind of the same thing on a HON. I will make an edit to reflect this!

1 Like

I definitely think this document, in a perfect world, would have some images of the graph itself, showing tags and links working together. It’s a very difficult concept to put into words, so I didn’t try, but it’s something I’ll think on how to express better, certainly.

Thank you @johw and @pop! That’s exactly the kind of nuanced feedback I was hoping for. I think I can probably refine the language, by giving an example.

There are many cases where search and replace will give you bad results. It’s super easy to intend to change #cat to #dog, and now on accident you have a #dogagory tag!

It is also not a reservable action, in most cases, so you might accidentally change a set of tags to have the same name as an existing tag, and you won’t be able to separate the two ideas again.

So, I do stand by the “risky” statement, but I could also provide more concrete examples of why. The intention isn’t to steer people away from (or to) find-and-replace, but to identify a key difference between links and tags, and provide evidence for why auto-refactoring is pretty awesome. :slight_smile:


Tags can also be useful for plugins like dataview / map view / tasks plugin to create a quick filter

1 Like

Yes, risky is the right word here

I recently adopted PARA in my Obsidian tagging and I came across some tag refactoring that Tag Wrangler plugin (which is a-w-e-s-o-m-e) could not handle.

So I opened up my vault in Sublime Text and did files Search and Replace to refactor the problem tags and their nested descendents.

Example (not the case that Tag Wrangler could not handle): to refactor mytag/* to Area/mytag/* (where my tags can included “-”)

I ran a files Search and Replace on md files using:

  1. search term regex: #mytag((/[\w-]+)* )
  2. replace term: #Area/mytag\1

where \1 is the first capture group

Sublime then opens up tabs for each markdown file without saving the change. I was then able to verify that the replacements were correct and save the files.

This process seemed to de-risk mangling the tags in my notes.

What do you guys reckon?

1 Like

TagWrangler is awesome, and definitely de-risks tag renaming significantly. Not fully, but significantly. Enough that I feel comfortable using tags for more cases than I did by default.

I think for people who are confident with regex and using an editor like Sublime or VSCode those tools definitely offer help for refactoring tags. But not everyone is going to be comfortable with both/either of those.

So I see no reason to discourage people with those abilities from using them, though. I still tend to avoid tags outside of some limited bounds, mostly because I don’t want to have to carefully check through N number of files when I change things. :stuck_out_tongue: But it does de-risk the process and is valuable for people to know about!

1 Like

One more notable property of tags in Obsidian is that they are transitive. If you create a hierarchy of tags:

  • Grandparent
    • Parent
      • Child

and then tag a note with #Child (#Grandparent/Parent/Child) to show if is related to the CHild category then it is automatically related to the Grandparent category and the Parent category as well. The tagged note will get listed in searches for any of #Granparent, #Parent, or #Child.


When to use tags/links?

To get the best out of both, first one should understand how they work (described in the post to which I’m answering).

Taking that into account, #tags could be seen as keywords when googling and [links] as hyperlinks in wikipedia.

Hope this clears out!


Actually, as the notes are stored within the file system, by the help of the bulk text replacement applied to all files within the vault using, such as VSCode or Atom, it is possible to replace the “#tag_1” to “[[tag_1]]”, and then the obsidian can do the rest works.

Vice versa.

1 Like

I’m currently working on posts for all the things I searched for and couldn’t find when starting out. The first is on how to approach tags. The gist is tags always sprawl and are always hard to maintain, and that’s ok because tags really only need to work at the note level. They’re like a jungle gym. You only need to know where the next bar is when you’re climbing around. It doesn’t matter how organized or messy the jungle gym looks from far away. https://austingovella.medium.com/how-to-approach-tags-in-your-pkm-b29c98dc43d3


And there is no difference to links, they also need to work on the note level. Thanks for that insight. - And it’s hard to believe that winning control by losing control is an amazing option in knowledge development.

@realactualprice been awhile since I’ve been in the forums so just saw your OP. Some really good info in there and a nice starting point for both tags and index pages.


The OP writes that

In Obsidian, a tag is: “A connection from a note to an idea”.

But I don’t think following that idea is wise. Your ideas should be notes, not tags. The note itself is the idea and the source of its information / knowledge generation power. The tag is the meta category that the note can - without a second thought - be related to. ie a logical and uncomplicated broad based filter!

Fundamentally it comes down to finding a good way to use tags for what they’re good for, which is identifying shared qualities of notes across different topics - but not qualities that directly link notes together (ie relations - thats what links should be used for). This is why a lot of people advocate for using tags as “statuses”.

Another cool use of tags I considered was location / time specific identification. So if you did a semester abroad, your could tag all notes that you write in that time away with #semester-abroad. ie, stuff thats useful for filtering later, but that isnt based on filtering down by topic - because that will always get way too granular and take too much consideration (a larger note could potentially have 5-10+ valid topical tags)

I read also this article about topic vs object tags. People said it was good but I didnt understand it on first read (have no idea why the thumbnail is that weird dog :rofl:)

In the end I would say that the style of using tags as broad based, cross topic groupings of notes (eg statuses #follow-up, timeframes #q1-2022, location based #semester-abroad or identifiers #meeting-notes) and using [[links]] as connections of direct bidirectional relationship mapping stands to bare the most fruit and take advantage of the power of obsidian in the long run.

Also keep in mind what kind of vault you are working in.
I have a technical reference vault for programming and there I only use tags as I want things to be very specific - and because its a technical reference doc, it is. So the tags then work as quick narrowing in on topics that are inherently specific.