Obsidian Properties: The Complete Guide

THE DEFINITIVE PROPERTIES GUIDE

If you've opened a note in Obsidian and noticed a neat panel of fields sitting above your text - tags, dates, checkboxes, links - you've already met Obsidian Properties. And if you've ever wondered what that --- block of text at the top of a Markdown file is, that's the same thing wearing its raw outfit: YAML frontmatter.

Properties are how Obsidian stores metadata - structured information about a note, separate from the note itself. A book note might have an author, a rating, and a date finished. A meeting note might have attendees and a project link. A recipe might have prep time and servings. None of that is prose. It's data. Properties give that data a proper home.

This guide covers everything: what Properties are, how the YAML frontmatter underneath works, every property type, how to create, edit, rename, and delete them, naming conventions, real-world setups for eighteen different use cases, deep integration with Bases, Dataview, Templater, and other plugins, twenty best practices, twenty common mistakes, performance advice for vaults with thousands of notes, and a 25-question FAQ.

Why did Obsidian build this at all? For years, frontmatter was a power-user feature. You typed raw YAML by hand, and one wrong indent silently broke your metadata. In version 1.4, Obsidian replaced that with a visual Properties editor. The goal was simple: make structured metadata something everyone can use, not just people comfortable editing config files. It worked. Properties are now the backbone of Bases, Obsidian's built-in database feature, and the foundation of nearly every serious organizational system in the app.

Who should use Properties? Honestly, anyone with more than fifty notes. Students tracking courses, developers documenting systems, researchers managing sources, writers tracking drafts, and anyone building a second brain. If you want to organize notes in Obsidian beyond folders and hope, Properties are the tool.

Let's start from the beginning.

What Are Obsidian Properties?

Properties are structured key-value pairs attached to a note. Each property has a name (the key) and a value. author: Cal Newport. rating: 4. completed: true. That's it at the core. Everything else in this guide builds on that one idea.

Metadata vs Note Content

Your note has two layers:

• Content - the actual writing. Paragraphs, headings, lists, ideas.
• Metadata - facts about the note. When it was created, what it's about, what status it's in, what it connects to.

The distinction matters because these two layers serve different purposes. You read content. You query metadata. When you ask "show me every book I rated 5 stars in 2025," you're not asking Obsidian to read your reviews. You're asking it to scan structured data. Content can't answer that question reliably. Metadata can, instantly.

YAML and Frontmatter, Explained Simply

Under the hood, every property is stored as YAML inside a frontmatter block. YAML (it stands for "YAML Ain't Markup Language") is a human-readable data format. Frontmatter is a convention: a YAML block placed at the very top of a Markdown file, fenced by three dashes.

Here's what a real note looks like in source mode:

---
title: Deep Work
author: Cal Newport
rating: 5
status: finished
date-finished: 2026-03-14
tags:
  - books
  - productivity
---

Everything between the two --- lines is frontmatter. Everything after the second --- is your note content. The frontmatter block must start on line 1 of the file. If there's even a blank line above it, Obsidian treats it as plain text.

Why Obsidian Changed the Interface

Before version 1.4, you edited frontmatter as raw text. It looked technical, it was easy to break, and most users ignored it. The Properties UI changed three things:

1. Validation - Obsidian now warns you when a value doesn't match its expected type, instead of failing silently.
2. Type awareness - dates get a date picker, checkboxes get a toggle, links get autocomplete.
3. Discoverability - property names autocomplete across your whole vault, which quietly enforces consistency.

The raw YAML never went away. The panel is just a friendly editor for it. Power users can still switch to Source mode and type YAML directly, and both views stay in sync. That dual nature - approachable UI on top, plain text underneath - is very Obsidian.

Why Use Properties?

Fair question. Plenty of people use Obsidian for years with nothing but folders and links. Here's what Properties add.

Better organization. Folders force a note into exactly one place. Tags are flat labels. Properties are dimensional: a note can have a status, a project, a priority, and a due date all at once, and each dimension can be filtered independently.

Filtering and search. Obsidian's search supports property queries directly. Type [status:active] in the search bar and you get every note whose status property equals "active". No plugin required.

Databases. This is the big one since Obsidian Bases shipped. Bases turns sets of notes into sortable, filterable tables and card views - and every column in a Base is a property. No properties, no database.

Automation. Plugins like Templater and QuickAdd can read and write properties programmatically. That means notes that fill in their own metadata when created.

Templates. A template with pre-defined properties means every book note, meeting note, or project note in your vault has an identical structure. Consistency is what makes querying possible later.

Plugin ecosystem. Dataview, Tasks, Kanban, Projects, Metadata Menu - dozens of major plugins are built around reading note metadata. Properties are the shared language.

Future scalability. A vault of 200 notes doesn't need much structure. A vault of 5,000 does. Properties added early cost seconds per note. Properties retrofitted later cost a weekend. The habit pays compound interest.

Note: Properties are stored as plain text inside your Markdown files. If you ever leave Obsidian, your metadata leaves with you. Nothing is locked in a proprietary database.

How Properties Work

Let's get precise about the mechanics, because understanding storage saves you from most beginner mistakes.

Where Properties Live

Every property is text in the frontmatter block of the note's .md file. There is no hidden database. When Obsidian starts, it indexes the frontmatter of every file into an internal metadata cache, which is what makes search and Bases fast. But the source of truth is always the file itself. Edit the YAML in any text editor, and Obsidian picks up the change.

Reading and Writing

You interact with properties three ways:

1. The Properties panel in Live Preview or Reading view - the visual editor most people use.
2. Source mode - raw YAML, full control, no guardrails.
3. Programmatically - via plugins (Templater, QuickAdd, Metadata Menu) or external scripts, since it's all plain text.

All three write to the same place. Pick whichever fits the moment.

A Quick YAML Syntax Primer

You'll rarely hand-write YAML once you use the panel, but knowing the rules helps you fix things when they break:

---
# Text values usually don't need quotes
title: My Great Note

# Quote values that contain colons or special characters
description: "Chapter 2: The Setup"

# Numbers are written bare
rating: 4.5

# Booleans are true or false, lowercase
published: false

# Dates use ISO format
due: 2026-08-01

# Lists use indented dashes
tags:
  - writing
  - drafts

# Internal links must be quoted
project: "[[Website Redesign]]"
---

Two rules cause 90% of YAML errors: indentation must use spaces, not tabs, and values containing a colon must be quoted. Remember those two and you'll almost never break frontmatter.

Every Property Type in Obsidian

Obsidian assigns each property a type, and the type controls both how the panel renders the field and how features like Bases sort and filter it. Here's the full lineup.

A few of these deserve individual attention.

Text

The default type. Anything you type is stored as a string.

status: in-progress
author: Ursula K. Le Guin

Best practice: for status-like fields, decide on a fixed set of values ("idea", "active", "done") and stick to them. Text properties autocomplete previously used values, which helps, but nothing stops you from typing "In Progress" one day and "in-progress" the next. To a query, those are different values.

Common mistake: storing dates as text. due: next Friday looks fine to you and means nothing to a filter.

List and Multi-select

Both store arrays of strings. Functionally they're the same thing; the panel just renders each entry as a removable pill.

attendees:
  - Sarah
  - Miguel
  - Priya

Best practice: use lists whenever a field could ever hold more than one value, even if it usually holds one. Converting a text property to a list later means touching every note that uses it.

Common mistake: writing attendees: Sarah, Miguel on one line. That's a single string containing a comma, not a list of two people.

Number

Stores integers or decimals, sorts numerically.

rating: 4.5
pages: 312

Best practice: keep units out of the value. price: 24.99 sorts; price: $24.99 is text and sorts alphabetically. Put the unit in the property name if needed (price-usd).

Common mistake: quoting numbers. rating: "5" is a string, and "10" sorts before "2" alphabetically.

Checkbox

A boolean. Checked is true, unchecked is false.

published: false
reviewed: true

Best practice: name checkboxes as yes/no questions or states: published, archived, reviewed. If you find yourself wanting a third state, you actually want a text status property instead.

Common mistake: typing published: no in source mode. YAML sometimes interprets bare yes/no oddly, and Obsidian expects strict true/false.

Date and Date & Time

Dates store as ISO 8601 (2026-08-01), date & time adds the clock (2026-08-01T14:30). The panel gives you a native picker for both.

due: 2026-08-01
meeting-start: 2026-08-01T14:30

Best practice: always use the picker or ISO format. ISO dates sort correctly as plain text, which is exactly why the standard exists.

Common mistake: regional formats. due: 01/08/2026 is ambiguous (August 1st or January 8th?) and won't be treated as a date at all.

Tags

The tags property is special. It's the frontmatter home for Obsidian's native tag system - anything listed here appears in the tag pane and tag search, identical to inline #tags in the body.

tags:
  - projects/website
  - review

Best practice: don't include the # symbol in frontmatter tags. It's implied. Nested tags with / work fine.

Common mistake: creating a second property called tag or Tags. Only the exact lowercase key tags connects to the native tag system.

Link

Internal links to other notes, stored as quoted wikilinks.

project: "[[Website Redesign]]"
related:
  - "[[Design System]]"
  - "[[Q3 Goals]]"

Link properties show up in the graph view and backlinks, which makes them my favorite type. A project link on fifty notes quietly builds a hub-and-spoke structure with zero extra effort.

Best practice: the quotes are mandatory in raw YAML. Without them, the brackets confuse the parser. The panel adds them automatically.

Common mistake: typing plain note names without brackets. project: Website Redesign is just text - no backlink, no graph edge, breaks if the note is renamed.

URL

External web links. Stored as text, but Obsidian renders anything starting with http as clickable.

source: https://help.obsidian.md/properties

Best practice: name the property for what the URL is (source, repo, docs), not just url or link, which get vague fast.

Changing a Property's Type

Property types are assigned per property name, vault-wide. Open the All Properties view in the sidebar (or the Properties core plugin settings), find the property, and change its type from the icon menu. Every note using that name follows the new type. If existing values don't fit the new type, Obsidian flags them with a warning icon rather than deleting anything.

Creating Properties

There are more ways to add a property than most people realize. Use whichever fits your hands.

1. The keyboard shortcut. With a note open, press Ctrl+; (Cmd+; on Mac). The panel appears and a new empty field is focused. This is the fastest method and the one worth memorizing.

2. The command palette. Ctrl+P, then "Add file property". Same result, no shortcut memorization required.

3. The file menu. Click the three-dot menu in the top right of a note and choose "Add file property".

4. Typing `---` on line one. In an empty note, type three dashes on the first line and press Enter. Obsidian creates the frontmatter block and switches to the property editor.

5. Source mode. Toggle to source mode and write YAML directly. Best for bulk edits or unusual structures.

6. Templates. The scalable answer. Define properties once in a template, and every note created from it starts with the right fields. More on this later.

When you type a property name, Obsidian autocompletes from every property name already in the vault. Accept the suggestion whenever one fits. This one habit prevents the author / Author / authors fragmentation that ruins queries.

Editing Properties

Every way to change an existing value:

• Click and type in the panel. Text and numbers edit inline; dates open the picker; checkboxes toggle; lists accept entries with Enter.
• Source mode for raw YAML edits, useful when pasting many values at once.
• The All Properties sidebar for vault-wide operations on a property name.
• Search and replace across files (carefully) for mass value changes, since it's all plain text.
• Plugins - Metadata Menu adds bulk editing, QuickAdd and Templater can modify properties from scripts, and Bases lets you edit property values directly in table cells, spreadsheet-style. That last one is genuinely the fastest way to update twenty notes at once.

Tip: Editing a property value inside a Bases table writes straight back to each note's frontmatter. If you maintain any collection of similar notes, do your metadata gardening from the table view, not note by note.

Deleting Properties

To remove a property from one note, hover over it in the panel and click the menu icon, then Remove - or just delete the line in source mode.

To remove a property from many notes, there's no native bulk-delete. Your options:

1. Bases or Dataview - list every note containing the property, then work through them.
2. Search - query ["property-name":] to find all notes with the property (any value), then remove manually.
3. Regex search-and-replace in an external editor like VS Code across your vault folder. Fast, but back up first.
4. Metadata Menu or a Templater script for an in-app scripted approach.

An orphaned property name (used by zero notes) disappears from suggestions on its own. If a stale name lingers, remove it from the suggestion list in the All Properties view.

Renaming Properties

Here's an unpleasant truth: renaming a property in one note does not rename it anywhere else. Change status to state in one file and the other 400 notes still say status. Now your queries need to check both.

The right procedure for a vault-wide rename:

1. Back up your vault (it's plain files - copy the folder).
2. Search ["old-name":] to scope how many notes are affected.
3. Use a regex replace across files in an external editor: replace ^old-name: with new-name: (with the multiline flag).
4. Reopen Obsidian and confirm in the All Properties view that the old name shows zero uses.
5. Update any Bases filters, Dataview queries, and templates that referenced the old name.

Step 5 is the one people forget. Queries fail silently - they just return fewer results - so broken references can hide for weeks.

Warning: Because renames are painful, spending five minutes choosing good names up front is one of the highest-value moves in this entire guide.

Property Naming Conventions

Consistency beats cleverness. Here's a convention set that has held up across years of daily use:

Three names have built-in behavior and should only be used for their intended purpose: tags (native tag system), aliases (alternative names that resolve in links and search), and cssclasses (per-note CSS styling). Everything else is yours to define.

Whatever you choose matters less than choosing once. Write your conventions in a note called "Vault Conventions" and glance at it before inventing any new property. Future you says thanks.

Real-World Property Examples

Theory's done. Here's what Properties look like in eighteen actual use cases. Steal freely - these are starting points, not prescriptions.

Students

---
type: lecture
course: "[[BIO-201]]"
professor: Dr. Okafor
date: 2026-02-10
week: 4
exam-relevant: true
tags: [university, biology]
---

The exam-relevant checkbox is the sleeper hit. Come finals week, one search surfaces every note you flagged all semester.

Developers

---
type: snippet
language: typescript
framework: react
tested: true
source: https://github.com/example/repo
related: "[[Frontend Patterns]]"
---

Project Management

---
type: project
status: active
priority: high
owner: "[[Sarah Chen]]"
start: 2026-06-01
due: 2026-09-30
budget: 15000
stakeholders: [Marketing, Engineering]
---

Pair this with a Base filtered to type = project and you have a live portfolio dashboard.

Daily Notes

---
type: daily
date: 2026-07-26
mood: 7
sleep-hours: 6.5
exercised: true
highlight: Shipped the properties guide
---

Numeric mood and sleep-hours values become chartable data over months. Text values don't.

Knowledge Management

---
type: evergreen
status: seedling
confidence: medium
sources: ["[[Deep Work]]", "[[Attention Residue Study]]"]
last-reviewed: 2026-05-12
---

The status: seedling/growing/evergreen pattern (borrowed from digital gardening) tracks how developed an idea is.

Research

---
type: paper
authors: [Kahneman, Tversky]
year: 1979
journal: Econometrica
doi: https://doi.org/10.2307/1914185
read-status: annotated
relevance: 5
---

Books

---
type: book
author: "[[Octavia Butler]]"
genre: [sci-fi]
status: finished
rating: 5
date-started: 2026-01-03
date-finished: 2026-01-19
pages: 345
---

Making author a link means every author gets an automatic page collecting all their books via backlinks.

Movies

---
type: movie
director: Denis Villeneuve
year: 2024
rating: 4
watched-with: [Alex]
rewatch: true
---

Recipes

---
type: recipe
cuisine: thai
prep-minutes: 15
cook-minutes: 25
servings: 4
vegetarian: true
tried: true
rating: 4
---

"Show me vegetarian recipes under 30 minutes that I've actually tried and liked" becomes a two-filter Base view.

Tasks

---
type: task
status: waiting
priority: medium
due: 2026-08-04
project: "[[Home Renovation]]"
delegated-to: contractor
---

Note: for granular checkbox tasks inside notes, the Tasks plugin is better. Note-level task properties suit bigger units of work - one note per deliverable.

CRM

---
type: person
company: Acme Corp
role: Head of Product
email: jordan@acme.example
last-contact: 2026-07-01
follow-up: 2026-08-01
relationship: warm
---

A Base sorted by follow-up date is a working CRM with zero extra software.

Journal

---
type: journal
date: 2026-07-26
gratitude: [morning run, quiet coffee]
energy: 8
themes: [career, health]
---

Second Brain

---
type: note
para: resources
area: "[[Writing]]"
status: processed
captured: 2026-07-20
source: newsletter
---

If you run PARA, a single para property (projects/areas/resources/archive) replaces folder gymnastics - moving a note between categories is a one-field edit.

Content Creation

---
type: article
status: drafting
platform: blog
target-keyword: obsidian properties
word-count-goal: 8000
publish-date: 2026-08-15
cover-made: false
---

This is close to the actual pipeline behind ObsidianMate posts. A Base grouped by status is the entire editorial kanban.

Software Documentation

---
type: doc
system: payments-api
doc-kind: runbook
last-verified: 2026-06-10
owner: platform-team
deprecated: false
---

last-verified is the killer field for docs. Sort ascending and you get an instant "most likely to be stale" list.

Meeting Notes

---
type: meeting
date: 2026-07-24
attendees: ["[[Sarah Chen]]", "[[Miguel Torres]]"]
project: "[[Website Redesign]]"
decisions-made: true
follow-up-needed: true
---

Bug Tracking

---
type: bug
severity: high
status: investigating
component: auth
reported: 2026-07-22
reproduced: true
assigned: "[[Me]]"
---

Architecture Documentation

---
type: adr
number: 14
status: accepted
date: 2026-05-30
supersedes: "[[ADR-009]]"
deciders: [platform-team]
---

Architecture Decision Records map to properties almost perfectly, and the supersedes link builds a decision lineage you can walk through the graph.

Notice the pattern across all eighteen: every note has a `type` property. That single convention is what lets Bases and Dataview treat "all books" or "all meetings" as coherent collections regardless of which folder they live in. If you adopt one idea from this section, adopt that one.

Properties + Templates

Templates are how properties scale. Without them, you're recreating the same fields by hand and inevitably drifting. With them, structure is automatic.

The core Templates plugin does the simple version. Make a note in your templates folder:

---
type: book
author:
genre:
status: to-read
rating:
date-started:
date-finished:
---

## Summary

## Notes

Insert it into any new note with the "Insert template" command. Empty values are fine - the fields exist, waiting.

Templater (the community plugin) adds dynamic values:

---
type: meeting
date: <% tp.date.now("YYYY-MM-DD") %>
attendees:
project:
created: <% tp.file.creation_date("YYYY-MM-DDTHH:mm") %>
---

The <% %> expressions evaluate at insertion time, so every meeting note stamps itself with today's date. Templater can also prompt you for values interactively when the note is created - name, project, priority - and slot the answers into frontmatter before you've typed a word.

Tip: Build one template per note type, and give each template the matching type property. Template count tends to stabilize around 6-10 for most vaults. More than that usually means your system is fancier than your actual needs.

Properties + Daily Notes

Daily notes are the highest-frequency notes in most vaults, which makes them the best place for lightweight metrics. Point the Daily Notes core plugin at a template like this:

---
type: daily
date: <% tp.date.now("YYYY-MM-DD") %>
mood:
sleep-hours:
exercised: false
---

## Log

## Tomorrow

Two rules keep this sustainable. First, only track what you'll fill in every single day - three fields you actually complete beat ten you abandon by February. Second, prefer numbers and checkboxes over text, because those aggregate. Six months of sleep-hours values is a chart. Six months of "slept okay I guess" is a diary.

The date property may look redundant when the filename is already the date, but it earns its place: it gives Bases and Dataview a real date value to sort and filter on without parsing filenames, and it survives any future filename format change.

Properties + Bases

Bases is Obsidian's built-in database feature, and it's the single biggest reason Properties went from "nice to have" to "core infrastructure." A Base takes a set of notes and displays them as a table or card gallery, where every column is a property and every row is a note.

How Bases Reads Properties

You create a Base as a .base file (or embed one in a note with a base code block). Inside, you define:

• Filters - which notes belong. Filters test property values: type = "book", status != "archived", rating >= 4.
• Views - how they display. Table views for data-heavy collections, card views for anything visual (books with covers, recipes with photos).
• Columns - which properties show. Reorder, hide, sort by any of them.
• Formulas - computed columns derived from properties, like calculating days until a due date or concatenating fields.

Here's a simple Base definition for a reading tracker:

filters:
  and:
    - type == "book"
views:
  - type: table
    name: Currently Reading
    filters:
      and:
        - status == "reading"
    order:
      - author
      - rating
      - date-started
  - type: cards
    name: Finished This Year
    filters:
      and:
        - status == "finished"
        - date-finished >= date("2026-01-01")

Editing Through Bases

This is the part that changes daily workflows: Base table cells are editable. Click a status cell, pick a new value, and the underlying note's frontmatter updates instantly. Updating metadata across a whole project stops being note-by-note archaeology and becomes spreadsheet work.

Why Types Matter More With Bases

Bases is strict about property types. A date-finished stored as text won't respond to date comparisons. A quoted number won't sort numerically. If a Base filter mysteriously excludes notes you know should match, the property type mismatch is the first thing to check - open the All Properties view and look for warning icons.

Bases vs Dataview

The honest recommendation in 2026: start with Bases. It covers 80% of what people historically installed Dataview for, it's maintained by the Obsidian team, and editable tables are something Dataview never offered. Reach for Dataview when you need query logic Bases can't express.

Properties + Dataview

Dataview remains the most installed community plugin, and it treats your properties as a queryable database.

Compatibility

Every frontmatter property is automatically a Dataview field. This note:

---
type: book
rating: 5
status: finished
---

...is queryable immediately:

TABLE author, rating, date-finished
FROM ""
WHERE type = "book" AND rating >= 4
SORT date-finished DESC

One syntax quirk: property names with dashes need brackets or normalization in some contexts - date-finished is accessed as row["date-finished"] in expressions, or via Dataview's normalized form date-finished. Test your queries; don't assume.

Inline Fields and Migration

Dataview also supports inline metadata written in the note body as key:: value. Before the Properties UI existed, many vaults leaned on inline fields heavily. If that's you, know two things: the Properties panel doesn't show inline fields, and Bases can't see them at all. Migrating inline fields into frontmatter is worth doing for any field you filter on regularly. Move them gradually - Dataview reads both locations, so nothing breaks mid-migration.

Query Examples Worth Stealing

Stale documentation finder:

TABLE last-verified, owner
FROM ""
WHERE type = "doc" AND last-verified < date(today) - dur(90 days)
SORT last-verified ASC

Unrated finished books (metadata gaps):

LIST
WHERE type = "book" AND status = "finished" AND !rating

That second pattern - querying for missing properties - is Dataview's most underrated trick. It turns metadata hygiene from a chore into a checklist that maintains itself.

Best Practices With Dataview

• Query by type property, not by folder, so reorganizing folders never breaks queries.
• Keep a "Queries" note documenting every non-trivial query you rely on and which properties it expects.
• Prefer frontmatter over inline fields for anything Bases might ever need.
• When a query returns fewer results than expected, check for type mismatches and name typos before blaming Dataview.

Properties + Community Plugins

Properties are the shared language of the plugin ecosystem. A quick tour of how the major players use them:

Templater - reads and writes properties at note creation, prompts for values, stamps dates. The automation backbone. Covered above.

Dataview - queries properties. Covered above.

Tasks - primarily works with inline checkbox tasks, but respects note-level context; many setups combine a project link property on the note with Tasks queries scoped to it.

Calendar - lights up daily notes on a calendar grid. Pairs with date properties for navigation, and clicking a date jumps to that daily note and its metrics.

QuickAdd - capture workflows that create notes with pre-filled properties from a prompt chain. "New book" can ask for title, author, and genre, then generate a fully-propertied note in three seconds.

Periodic Notes - extends daily notes to weekly, monthly, quarterly. Weekly notes with rollup properties (week-rating, main-win) make reviews queryable.

Metadata Menu - the power tool. Adds field definitions per note type, dropdown value constraints, and bulk editing. If you want status to only ever accept four specific values, this plugin enforces it.

Buttons - clickable buttons in notes that trigger commands, including Templater scripts that modify properties. A "Mark Complete" button that flips status to done and stamps completed-date is a ten-minute build.

Projects - a database-view plugin that predates Bases and reads the same frontmatter. Still liked for its board views, though Bases has absorbed much of its audience.

Minimal Theme - reads the cssclasses property to restyle individual notes: wide tables, hidden titles, image grids. A reminder that properties can control presentation, not just data.

Note: For a broader look at the ecosystem, see our guide to must-have Obsidian plugins - several of the picks there work best in vaults with consistent properties.

Advanced Workflows

A few patterns that only click once properties, templates, and queries are working together:

The self-maintaining review queue. Give evergreen notes a last-reviewed date and a review-interval number. A Dataview query surfaces notes where today exceeds last-reviewed plus the interval. Reviewing a note means updating one date field. Spaced repetition for ideas, no flashcards.

Status-driven publishing pipeline. Content notes carry status (idea, drafting, editing, scheduled, published) plus platform and publish-date. One Base with a view per status is a full editorial kanban. When a post ships, flip the status in the table view - done.

The people graph. Every person gets a note. Every meeting note links attendees via a link-list property. Every person note's backlinks become an automatic interaction history. Add a follow-up date property and a sorted Base becomes your relationship dashboard.

Metadata-gap dashboards. A note full of queries that find incomplete metadata: finished books without ratings, projects without owners, docs unverified in 90 days. Five minutes a week keeps the whole vault query-ready.

Property-driven CSS. Combine cssclasses with per-type templates so every recipe note automatically gets recipe styling, every dashboard gets wide-mode. Structure and presentation from the same YAML block.

20 Best Practices for Obsidian Properties

1. Give every note a `type` property. It's the foundation of every query and Base you'll ever build.
2. Write your conventions down in a "Vault Conventions" note and check it before creating new property names.
3. Use kebab-case consistently for multi-word names. Any convention works; mixing conventions doesn't.
4. Accept autocomplete suggestions when adding properties. Fragmented names are the number one source of broken queries.
5. Prefer the date picker over typing dates. ISO format or nothing.
6. Keep units out of number values. price-usd: 24.99, never price: $24.99.
7. Make it a list if it could ever be plural. Converting later is painful.
8. Use link properties for entities (people, projects, sources) so relationships appear in backlinks and the graph.
9. Define fixed value sets for status fields and never improvise new ones mid-week.
10. Start with 3-5 properties per note type. Add fields when a real query needs them, not before.
11. Put properties in templates, not in your memory.
12. Query by properties, not folders, so reorganizing your vault never breaks anything.
13. Check the All Properties view monthly for duplicates, typos, and type warnings.
14. Track daily-note metrics as numbers and checkboxes, not prose, so they aggregate.
15. Add a `created` date via template rather than trusting file-system timestamps, which sync tools mangle.
16. Reserve `tags`, `aliases`, and `cssclasses` for their built-in purposes.
17. Use Bases table editing for bulk updates instead of opening notes one by one.
18. Build metadata-gap queries so incomplete properties surface themselves.
19. Back up before any vault-wide rename or regex operation. It's one folder copy.
20. Delete properties you stopped using. Dead fields in templates train you to ignore all fields.

20 Common Mistakes (and How to Avoid Them)

1. Blank line above the frontmatter. The --- block must start on line 1. Fix: delete anything above it.
2. Tabs in YAML. Tabs break parsing. Fix: spaces only; the panel handles this for you.
3. Unquoted colons in values. title: Chapter 2: Setup fails. Fix: quote the whole value.
4. Unquoted wikilinks. project: [[X]] confuses the parser. Fix: project: "[[X]]".
5. Case-fragmented names (Author vs author). Fix: lowercase everything, accept autocomplete.
6. Singular/plural drift (tag, tags, Tag). Fix: only tags connects to the tag system.
7. Dates as free text. "next Friday" filters as nothing. Fix: the picker.
8. Regional date formats. 01/08/2026 is ambiguous and untyped. Fix: ISO.
9. Quoted numbers. rating: "5" sorts alphabetically. Fix: remove quotes, verify type is Number.
10. Comma lists in one line as text. attendees: A, B is one string. Fix: use the list widget or YAML dashes.
11. Renaming in one note and assuming vault-wide effect. Fix: follow the rename procedure above.
12. Forgetting queries after renames. Fix: keep a Queries note listing property dependencies.
13. Including `#` in frontmatter tags. Fix: bare tag names.
14. Twenty-field templates. Nobody fills them. Fix: start minimal.
15. Duplicating the filename as a `title` property with no purpose. Fix: only add title if something consumes it.
16. Storing paragraphs in properties. Metadata is for facts. Fix: prose goes in the body.
17. Inline Dataview fields for data Bases needs. Bases can't see key:: value. Fix: migrate to frontmatter.
18. Trusting file timestamps as metadata. Sync resets them. Fix: explicit created property.
19. Ignoring type-mismatch warning icons. They're why your filter "doesn't work." Fix: All Properties view, fix the type or value.
20. No backup before bulk regex edits. One bad pattern can touch a thousand files. Fix: copy the vault folder first, every time.

Performance Tips for Large Vaults

Properties are lightweight - they're a few lines of text per file - but at thousands of notes, habits start to matter.

Frontmatter itself is nearly free. Obsidian's metadata cache indexes properties on startup and updates incrementally. A 10,000-note vault with clean frontmatter opens fast. Property count per note barely matters; keep it under ~15 for sanity, not speed.

Queries are where cost lives. A Dataview query scanning FROM "" (the whole vault) on every dashboard open is doing real work. Scope queries with FROM sources or early WHERE type = filters. Bases is generally efficient here since filters are indexed against the cache.

Avoid dashboards with many live query blocks all rendering at once, especially on mobile. Ten Dataview blocks on one note means ten scans on open. Consolidate, or split dashboards by context.

Fewer distinct property names beat more. 30 well-reused names across 10,000 notes is a healthier vault than 400 one-off names - less for autocomplete to churn, less for you to remember, and cleaner Base column pickers.

Watch plugin overlap. Metadata-heavy plugins each maintain their own indexes. If Bases now does what Projects and half your Dataview usage did, retire the redundancy.

Sync large vaults carefully. Property edits touch files, files trigger sync. That's fine, but a bulk regex operation across 3,000 files right before a mobile sync makes for an exciting afternoon. Do bulk edits, verify, then sync.

Frequently Asked Questions

What are Properties in Obsidian?

Properties are structured metadata attached to a note as key-value pairs - things like author, status, rating, or due date. They're stored as YAML frontmatter at the top of the Markdown file and edited through a visual panel in the note.

What is frontmatter in Obsidian?

Frontmatter is a YAML block at the very top of a Markdown file, fenced by --- lines. Obsidian's Properties panel is a visual editor for this block; the panel and the raw YAML are two views of the same data.

Are Properties the same as YAML frontmatter?

Yes. Properties are Obsidian's user-friendly interface for YAML frontmatter. Edit one and the other updates instantly.

How do I add a property to a note?

Press Ctrl+; (Cmd+; on Mac), or run "Add file property" from the command palette, or type --- on the first line of an empty note. Then type a name and value.

How do I show hidden properties?

If properties aren't visible, check Settings, then Editor, then "Properties in document" and set it to Visible. Choosing Source mode shows raw YAML instead, and Hidden hides the panel entirely.

What property types does Obsidian support?

Text, list, number, checkbox, date, date & time, tags, aliases, and cssclasses. Links and URLs are stored as text but get special rendering, autocomplete, and graph behavior.

How do I change a property's type?

Open the All Properties view in the sidebar, click the icon next to the property name, and select "Property type." The change applies vault-wide to that property name.

Can a property have multiple values?

Yes. Use the List type. Each value becomes a separate entry, stored as a YAML array. Tags and aliases are always lists.

How do I link to another note in a property?

Type [[ in the property value and pick a note from the autocomplete. In raw YAML the link must be quoted: project: "[[Note Name]]".

Do link properties show up in the graph view?

Yes. Links in properties create real connections that appear in the graph and in backlinks, just like links in the note body.

How do I search notes by property?

Use the syntax [property:value] in Obsidian's search - for example [status:active]. Use [property:] with no value to find every note that has the property at all.

How do I rename a property everywhere at once?

Obsidian has no built-in vault-wide rename. Back up your vault, then run a regex find-and-replace across files in an external editor (replace ^old-name: with new-name:), then update any queries and templates that used the old name.

How do I delete a property from all notes?

There's no native bulk delete. Find affected notes with the search [property-name:], then remove the field manually, through Bases, or with a scripted find-and-replace in an external editor.

Why is my property showing a warning icon?

The value doesn't match the property's assigned type - usually text in a number field or a non-ISO date in a date field. Fix the value or change the type in the All Properties view.

Why doesn't my frontmatter work?

The four usual causes: the --- block doesn't start on line 1, indentation uses tabs, an unquoted value contains a colon, or a wikilink isn't wrapped in quotes.

Do Properties work on mobile?

Yes. The Properties panel, pickers, and Bases all work in the Obsidian mobile apps, and property edits sync like any other file change.

What's the difference between tags and properties?

Tags are flat labels answering "what topics touch this note." Properties are typed key-value data answering specific questions like status, rating, or due date. Tags live inside the special tags property when written in frontmatter.

Should I use properties or folders to organize notes?

Use both, but query by properties. Folders give a rough physical home; properties provide the dimensions (type, status, project) that filtering and Bases actually use. Property-based queries survive folder reorganizations.

What are Bases and how do they use properties?

Bases is Obsidian's built-in database feature. It displays sets of notes as tables or card galleries where columns are properties, filters test property values, and cells are editable - edits write back to each note's frontmatter.

Does Dataview work with Properties?

Fully. Every frontmatter property is automatically a queryable Dataview field. Dataview additionally supports inline key:: value fields in the note body, which the Properties panel and Bases don't read.

Should I use Bases or Dataview?

Start with Bases: it's built in, visual, and supports inline editing. Add Dataview when you need complex query logic, JavaScript, or inline fields that Bases can't handle. Many vaults happily run both.

Can templates include properties?

Yes, and they should. Define frontmatter in a template and every note created from it starts with identical fields. Templater can fill values dynamically - dates, prompts, computed text - at creation time.

What are the reserved property names?

Three: tags (native tag system), aliases (alternate note names for links and search), and cssclasses (custom CSS styling per note). Don't repurpose them.

How many properties should a note have?

Three to seven covers most note types well. Add a field only when a real filter or query needs it. Past roughly ten, notes become forms nobody enjoys filling in.

Do properties slow down large vaults?

Not meaningfully. Frontmatter is indexed into a fast metadata cache. Performance issues in big vaults almost always come from heavy unscoped queries or too many live query blocks rendering at once, not from the properties themselves.

Can I edit properties outside Obsidian?

Yes. Properties are plain text in your .md files, so any editor or script can read and modify them. Obsidian picks up external changes automatically. That portability is the whole point.

Wrapping Up

Properties look small - a few labeled fields above your note - but they're the difference between a pile of documents and a system that answers questions. The recipe that works: give every note a type, define a handful of well-named fields per type, bake them into templates, and let Bases or Dataview turn the structure into views you actually use.

Don't build the whole cathedral this weekend. Pick one note type - books, meetings, whatever you create most - add three properties through a template, and make one Base view for it. Live with it for two weeks. Expand what earns its keep, delete what doesn't. Vaults built that way last; vaults designed in a single ambitious evening usually don't survive the month.

If this guide helped, a few good next reads on ObsidianMate: our comparison of Obsidian vs Notion (properties are Obsidian's answer to Notion databases, and the trade-offs are interesting), our roundup of must-have Obsidian plugins for the tools mentioned throughout this guide, our walkthrough on installing local plugins if you want Metadata Menu or niche property tools, and our guide to building an AI second brain, where consistent properties become the structure an assistant can actually reason over.

Coming soon in this series: a deep practical guide to Obsidian Bases, a Dataview-to-Bases migration walkthrough, and a template pack article with ready-made property schemas for every use case covered above. The official Obsidian help docs on properties, the Dataview documentation, and the Templater docs are the authoritative references when you need exact syntax - this guide is the map; those are the street signs.

Now go add a type property to something.