Welcome to the NZRT Wiki Podcast. Today we’re looking at Frontmatter & Properties.

So, what is frontmatter? At its core, frontmatter is a block of structured metadata that sits at the very top of an Obsidian note. It’s written in a format called YAML, and it’s wrapped between two sets of triple dashes — one at the very start, one at the end of the block. Think of it as a label on a folder: it tells you and your tools what’s inside, without being part of the actual content.

That block of metadata is queryable by a plugin called Dataview, and it’s also filterable in Obsidian’s search. So it’s not just decoration — it’s functional.

Let’s talk about what that looks like in practice. The code example in the wiki shows a frontmatter block containing five fields. You’ve got a tags field holding two tag values. An aliases field with two alternative names for the note. A created date set to the twenty-fifth of May 2026. A status field set to active. And a type field set to reference. The key rule here: this block must appear at the absolute top of your file. There can’t be a blank line before that opening set of triple dashes — it has to be the very first thing in the document.

Now, if you’d rather not hand-edit that raw YAML, Obsidian version 1.4 and above gives you a much friendlier way to work with it. It’s called the Properties panel. You can open it by pressing Control and the semicolon key together, or by going to View and selecting Toggle Properties. What you’ll see is a clean graphical interface where all your frontmatter fields appear as typed input boxes — no angle brackets, no colons, no syntax to worry about. You just click and type.

That brings us to data types, and there are seven of them to be aware of. First is plain text — something like a title field containing a note name. Second is a number, useful for things like a priority field where you’d enter a digit. Third is a checkbox, which maps to a true or false value — handy for a done field. Fourth is a date, displayed as a date picker in the Properties panel. Fifth is date and time combined, which lets you capture both the day and a specific time, like ten thirty in the morning. Sixth is a list, where you can store multiple values in a single field — tags being the most common example. And seventh is a wikilink, which lets you link directly to another note from within your frontmatter.

There are also three built-in fields that Obsidian itself understands and acts on. The first is tags, which tags your note the same way an inline hashtag would in the body of the document. The second is aliases — this lets you give a note alternative names, and those names show up in link autocomplete and search results, so other notes can reference it by a different label. The third is cssclasses, which lets you apply custom CSS styling to a specific note. Everything beyond those three is user-defined, and only carries meaning if a plugin like Dataview or Templater knows to look for it — or if you’re using it for your own personal organisation system.

Speaking of Dataview — let’s talk about how you actually use frontmatter fields in a query. The example in the wiki shows a table query that pulls two fields, status and created, from notes inside a folder called Projects. It then filters to only show notes where the status field equals active, and sorts the results by the created date in descending order, so the most recent ones appear first. In plain terms: you’re asking Dataview to build a live table of your active project notes, newest at the top. Any frontmatter field you’ve defined can be used the same way — filtered, sorted, or displayed as a column.

Finally, there’s Obsidian’s built-in search. You can target frontmatter fields directly by wrapping them in square brackets with a colon between the field name and the value. For example, searching for status colon active inside square brackets finds every note where the status field is set to active. Searching for tags colon the code 000OBS inside square brackets finds every note tagged with that identifier. It’s a precise way to filter your vault without needing to run a full Dataview query.

So to recap: frontmatter sits at the top of your note, stores structured metadata in YAML format, supports seven data types, has three built-in fields Obsidian acts on natively, and can be edited either as raw text or through the Properties panel GUI. Plugins like Dataview can query it, and Obsidian’s search can filter by it directly.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Tags.

So what are tags in Obsidian? Simply put, tags are a way to categorise your notes so you can filter and search across them easily. And the good news is that Obsidian gives you two ways to add them, and both work exactly the same under the hood.

The first way is inline tagging, meaning you drop a tag right into the body of your note. You just type a hash symbol followed by a word, like hash-project or hash-status-active. The second way is through frontmatter, which is the block of metadata at the very top of your note. There you’d write something like tags, colon, and then list your tags in square brackets separated by commas. Both approaches are indexed identically by Obsidian, so it doesn’t matter which you use from a search perspective. That said, frontmatter tags are the preferred approach for structured notes because it keeps your note body clean and uncluttered.

Now let’s talk about nested tags, which are really useful once your vault starts to grow. You create a nested tag by putting a forward slash between levels. So for example you might have a tag for area-work, another for area-personal, and then status-active and status-archived. What this does is create a hierarchy. In the Tags panel on the left sidebar, those nested tags fold neatly under their parent. And here’s the handy part when it comes to searching: if you search for area, Obsidian will match everything under that parent, so all of your area-work and area-personal notes come back in one go. You don’t have to search each sub-tag individually.

Speaking of the Tags panel, you can find it in the left sidebar by clicking the Tags icon. It gives you a full list of every tag used across your entire vault, along with a count of how many notes carry each one. Click any tag in that panel and Obsidian immediately opens a search showing all the notes that use it.

Now let’s cover searching with tags directly, because there are a few different ways to do it. If you just type a hash followed by your tag word in the search bar, you’ll get notes that contain that tag inline in the body. If you want to catch tags whether they’re in the frontmatter or inline, you prefix your query with tag-colon and then your hash and tag name. And if you want to search across an entire nested tag family, you can type tag-colon, hash, your parent tag name, and then a forward slash, and Obsidian will return every note tagged with anything under that parent.

Finally, it’s worth understanding the difference between tags and folders, because you’ll be using both in a well-organised vault. There are a few key differences to keep in mind. With folders, a note lives in exactly one place on your filesystem. With tags, a single note can carry as many tags as you like. Folders give you a hierarchical, physical organisation structure. Tags give you cross-cutting categorisation that cuts across those folder boundaries. Both are queryable through Dataview, although the syntax differs slightly: for folders you use a FROM clause pointing to the folder path, while tags just filter by tag name. The practical takeaway is to use folders as your primary organisation method and tags for attributes that span multiple folders, things like status, note type, or service codes.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Vaults.

So, what exactly is a vault? Put simply, a vault is a folder on your disk. When you point Obsidian at that folder, it reads every markdown file inside it and builds a knowledge graph from the links between those files. That’s really the core idea — a vault is just a folder, and Obsidian does the rest.

Let’s talk about what you’ll find inside a typical vault. If you were to open one up in your file explorer, you’d see a top-level folder — let’s call it MyVault. Inside that, there’s a hidden folder called dot-obsidian, and that’s where Obsidian stores all its settings for that vault: things like your plugins, your themes, and your keyboard shortcuts. Everything else in the vault is your actual content — plain markdown files and any attachments you’ve added. So you might have a Notes folder, a Projects folder, a Templates folder — whatever structure works for you. Your content and your Obsidian settings live side by side, but they’re cleanly separated.

Now, one thing that trips people up at first is the idea of multiple vaults. Obsidian fully supports having more than one vault, and each one is completely independent. That means each vault has its own set of settings — its own plugins, its own theme, its own keyboard shortcuts. Each vault also has its own graph, which is important: links between notes only resolve within the same vault. If you’ve got a note in one vault that you try to link to from another vault, Obsidian won’t connect them. Each vault also maintains its own recent files list, its own search index, and its own plugin state. So if you’ve got a plugin configured a certain way in one vault, that configuration doesn’t carry across to another. To switch between vaults, you can go to File, then Open Another Vault, or use the vault switcher shortcut.

Speaking of opening vaults, there are three main ways to do it. First, you can open an existing folder — just go to File, Open Vault, then choose Open Folder as Vault, and point it at any folder on your machine. Second, you can create a brand new vault from scratch using the Create New Vault option in that same menu. And third, the vault switcher shows you all the vaults you’ve previously opened, so you can jump back to any of them quickly.

Now let’s dig into that dot-obsidian folder a bit more, because it’s worth understanding what lives in there. There are several key files and subfolders to know about. First is a file called app dot json — that holds your core settings, like editor preferences, appearance options, and how Obsidian handles files and links. Then there’s a plugins subfolder, which is where your installed community plugins live. There’s a themes subfolder for your installed themes. There’s a file called hotkeys dot json, which stores any custom keyboard shortcuts you’ve set up. If you’re using the Templates core plugin, you’ll also see a templates subfolder in there. And finally there’s workspace dot json, which saves your current layout — which panes are open, which tabs you have active, and the state of your sidebars.

Here’s a practical tip around syncing. If you sync your vault across devices — say between your desktop and your laptop — you’ll want to include the dot-obsidian folder in your sync setup. That way your settings, plugins, and themes follow you to every device. However, there’s one exception worth knowing: workspace dot json. If you don’t want your pane layout to sync — maybe you prefer a different arrangement on each machine — you can exclude that file from your sync. Small detail, but handy to know.

Finally, let’s talk about performance. The good news is that Obsidian handles large vaults very well — we’re talking tens of thousands of notes without breaking a sweat. But there are a few things that can slow it down. Very large individual files, anything over about one megabyte, can cause performance issues. Having too many community plugins installed is another common culprit. And if you’re using Dataview — a popular plugin for querying your notes like a database — running heavy queries across a massive vault without caching enabled can put a real strain on things. So if you notice Obsidian getting sluggish, those are the three areas to look at first: individual file size, plugin count, and how efficiently your Dataview queries are running.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Wikilinks & Backlinks.

If you use Obsidian as your knowledge base, wikilinks are probably the feature you’ll reach for the most. Every link you create is bidirectional — meaning the note you’re linking to automatically knows it’s been referenced. That’s what makes Obsidian’s knowledge graph so powerful, and it all starts with understanding the syntax.

The wiki lays out eight different ways to create a wikilink, so let me walk you through them in plain language.

The simplest form is just wrapping a note’s filename in double square brackets. That creates a direct link to that note by name. If you want the link to display different text to the reader — say you want it to read “our onboarding guide” but it actually points to a note called New Staff Process 2026 — you can add a separator between the note name and the display text you want shown. The link works the same way, it just looks different on screen.

If you want to be more precise about which note you’re pointing to — which is a good idea in larger vaults where notes in different folders might share similar names — you can include the full folder path from the vault root, not just the filename.

You can also link to a specific section inside a note rather than the whole thing. By appending the heading name after the note name, Obsidian will jump straight to that heading when you follow the link. There’s also a block-level version of this — instead of a heading, you link to a specific paragraph or list item using a block identifier that Obsidian generates for you.

Then there are embed links. These are a step beyond regular links — instead of just pointing to a note, they pull that content directly into the current page inline. You can embed a full note, just a specific section of a note, or an image file. All three work the same way, just with a different target.

Now let’s talk about how Obsidian figures out which note you mean when you write a link. It follows a two-step process. First, it looks for an exact path match from the vault root. If it doesn’t find one, it searches for any note with that filename anywhere in the vault, and if there are multiple matches it picks the one with the shortest path. To avoid ambiguity — especially as your vault grows — the recommendation is to always use the full path from the vault root.

Next up is one of the most useful features Obsidian offers: the Backlinks panel. You’ll find this in the right sidebar of any note, and it shows you two things. First, linked mentions — notes that have explicitly created a wikilink pointing to the note you’re currently reading. Second, unlinked mentions — notes that mention your note’s title as plain text, without a formal link. That second category is particularly useful for finding connections you haven’t formalised yet. To enable it, go to Settings, then Core Plugins, and switch on Backlinks.

There’s also the Outgoing Links panel, which works the other way around. While backlinks show you what points to the current note, outgoing links shows you everything the current note points to. It breaks these down into resolved links — where the target note exists — and unresolved links, where the target hasn’t been created yet. Unresolved links appear in a different colour and show up as what the wiki calls a ghost node in the graph view. So even a link to a note that doesn’t exist yet leaves a visible mark, which can be a handy way to spot gaps in your knowledge base.

When you’re writing and want to insert a link, you trigger the autocomplete picker by typing two opening square brackets. This opens a fuzzy search across all your note titles, so you don’t need to type the exact name — just enough of it for Obsidian to recognise it. You can press Tab to accept a suggestion or Enter to open the note directly.

Finally, there’s Page Preview. If you hold the Control key and hover your mouse over any wikilink, a popup appears showing you that linked note’s content — without navigating away from what you’re currently reading. This requires the Page Preview core plugin to be enabled, which you’ll find alongside the others in Settings.

So that’s the full picture of wikilinks and backlinks in Obsidian — from creating links and embedding content, right through to understanding how the graph connects everything together.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.