Open any .md file inside an Obsidian vault in a plain text editor and it looks exactly like what it is — headings, lists, links, nothing exotic. Open the app instead, and the same file gets backlinks, a graph view, styled callout boxes, and instant navigation between notes.
None of that second list is some proprietary format bolted onto Markdown. It's a small set of syntax additions on top of standard Markdown, plus a live index the app keeps of the whole vault. Knowing exactly where that line sits — what's text sitting in the file versus what's computed by the app around it — is what determines how much of a vault survives when you open it somewhere else, including when an AI agent gets file access to it.
A vault is Markdown, plus an index
Everything Obsidian shows you falls into exactly two categories: text that's actually written in the .md file, and information the app computes by indexing every file in the vault but never writes back into the files themselves unless you explicitly ask it to. That distinction isn't obvious from inside the app — both categories render the same way, in the same pane, styled the same.
Everything the app shows you either lives in the file, or lives in an index built from all the files. Only one of those two travels with the file.
The rest of this article goes through Obsidian's actual syntax additions one at a time, then sorts them into those two buckets — because that sort is what decides what survives in GitHub, in a plain text editor, or in front of an AI agent that only has file access and no app.
Wikilinks — the core addition
Everything else in Obsidian is really built around one piece of syntax: the wikilink. Instead of a standard Markdown link pointing at a path, you write the note's name in double brackets, and Obsidian resolves it for you.
See the [[Pricing Model]] decision from last quarter, or give it a custom label: [[Pricing Model|the pricing decision]].
The practical advantage over a plain relative Markdown link — the kind used throughout Markdown as a living knowledge base — is that a wikilink resolves by note name, not by file path. Rename or move the file inside Obsidian, and every wikilink pointing at it updates automatically. A plain relative link to the old path just goes stale, silently, the moment the file moves. A note can also answer to more than one name, by listing extra names under aliases in its frontmatter.
Backlinks — computed, not written
This is the first item that falls into the "computed" bucket, not the "written" one. Nowhere in a note's actual file is there a list of what links to it — that panel is built live, by Obsidian scanning every other note in the vault for a link pointing back at this one.
It's genuinely useful — it's the payoff of bothering with wikilinks in the first place, turning a pile of notes into something you can navigate in both directions. But it is a report, generated on demand from the whole vault, not a fact stored in any single file. Open that file outside Obsidian, or hand it to a tool that only reads one file at a time, and the backlinks are simply gone — not hidden, not encoded somewhere, just never written down.
Callouts — an admonition wrapped in a blockquote
A callout is Obsidian's way of turning a plain blockquote into a styled admonition box — a note, warning, tip, or a handful of other types, with an optional custom title.
> [!warning] Don't skip this > Renaming a file outside Obsidian breaks every > wikilink that pointed at it — Obsidian only > rewrites links through its own rename action.
Because it's built on top of a real Markdown blockquote, this degrades better than most of Obsidian's additions: any plain renderer — GitHub, VS Code's preview, a bare CommonMark parser — still shows a blockquote. What it can't do is recognize [!warning] as a type, so that line just renders as ordinary text at the top of the quote, with the square brackets and all.
Embeds and tags — the rest of the syntax
Prefix a wikilink with ! and Obsidian pulls the target's content inline instead of just linking to it: ![[Note Name]] embeds a whole note, ![[Note Name#Heading]] embeds just one section of it, and ![[image.png]] embeds an image — replacing the standard  syntax with a wikilink-shaped one. Outside Obsidian, all three read as a broken image tag, since a plain Markdown parser expects a URL where the note name is.
Standard Markdown only gives # meaning at the start of a line, as a heading. Obsidian additionally treats #project as an inline tag wherever it appears in a sentence, indexing it for search and filtering — on top of, or instead of, listing tags in frontmatter. Outside the app, an inline tag is just inert text, unless it happens to sit at the start of a line, where a plain renderer will read it as a heading instead.
What survives outside the vault
Put the additions above side by side with what happens once the same file leaves Obsidian — opened in GitHub, a plain text editor, or a script that just reads bytes — and the pattern is consistent: everything stays legible as text, but only some of it still renders as intended.
| Feature | Inside Obsidian | Plain Markdown viewer | An AI agent reading the file |
|---|---|---|---|
Wikilink [[note]] |
Clickable, auto-updates on rename | Shows as literal [[note]] text |
Readable as-is — the intent is obvious |
| Backlinks | Live panel, per note | Doesn't exist — nothing to show | Has to be rebuilt by scanning every file |
Callout [!note] |
Styled admonition box | Plain blockquote, tag shown as text | Reads fine as a labeled blockquote |
Embed ![[note]] |
Note or image rendered inline | Broken image icon | Resolvable by filename, with file access |
Tag #project |
Indexed, clickable, filterable | Inert text (or a heading, at line start) | Trivially greppable |
What an AI agent sees when it reads the files directly
Markdown as a living knowledge base made the point that an AI agent with file access to a growing folder of notes can just grep and read, the same way a person would. A vault doesn't change that — every wikilink, callout, and tag is still plain text sitting in a plain file. What changes is which parts an agent gets for free, and which parts it has to build itself.
Wikilinks are the easy case: the link is literally written in the file, so an agent can find every note that points forward to another one with a single search — the same raw material Obsidian's own index is built from. Backlinks are the harder case, for exactly the reason covered above: they don't exist anywhere on disk. An agent that wants to know what points at a given note has to do what Obsidian's indexer does — read every file in the vault and build the reverse map itself. That's not a shortcoming of Obsidian; it's the actual shape of the problem any outside reader faces with a knowledge base, vault or not.
The same plain-files property is also why a vault works fine as the home for a spec-driven development project rather than just personal notes — the spec is just another note, read by an agent the same way it reads everything else in the folder.
The pattern
The vault is a convenience layer. The files underneath are the actual data.
Use wikilinks, callouts, and tags freely inside Obsidian — they're what make a vault pleasant to maintain day to day, and none of them threaten the underlying files' plain-text nature the moment you look at them in anything else.
What's worth being careful about is the computed layer — backlinks, the graph view — treating it as data when it's really a live report built from everything else in the vault. Nothing wrong with relying on it inside Obsidian; just don't design a workflow, or hand a folder to an AI agent, assuming that layer travels with a single file. It doesn't. Only the syntax does.
Further reading: Markdown as a living knowledge base · Spec-driven development — this is where Markdown really shines · Markdown as RAG — your own lightweight context layer