Breadcrumbs gives an Obsidian vault typed links and a visible hierarchy

Obsidian shows that two notes link, Breadcrumbs shows how

Obsidian's graph view records a link and stops there. Breadcrumbs is built on a different premise: that the relationship itself carries type information worth keeping. A note can point up to a parent, down to a child, forward to the next note in a sequence, or across a relation the user defines. Those typed links are then compiled into a directed graph.

The plugin layers several views on top of that graph. A breadcrumb trail at the top of a note shows its ancestors and the path back to the root. The Tree side view expands the full structure under the current note. The Matrix view groups incoming and outgoing relationships by type, which is the fastest way to see who points at a note and under which label. Previous and Next controls turn a chain of notes into something you can read front to back.

It also renders diagrams inside notes. A `breadcrumbs` codeblock renders a note's neighbourhood as a tree, as a Mermaid diagram, or as an interactive Markmap mind map. There is an export path too: the neighbourhood can be laid out as a native Obsidian Canvas with file nodes and labelled edges that you can rearrange and edit.

Structure is read from whatever convention the vault already uses

The plugin does not ask you to migrate your notes into one scheme. Breadcrumbs reads structure from frontmatter properties typed as links, from tags, from Markdown lists, from naming schemes, from folders treated as folder notes, and from Dataview queries.

The naming scheme list is specific: Dendron style parent.child paths, Johnny.Decimal style numbers such as 01.02 Title, dates, and custom regular expressions. In practice this means a vault can be organised by any of those conventions and Breadcrumbs will still construct the hierarchy.

On top of the relations you declare, the plugin derives implied relations on its own. The example given is inverse pairing: if A is up from B, then B is down from A. You can also write your own transitive rules, so a chain of up links can collapse into a direct ancestor relation. That derivation is the mechanism behind the trail view, which is why the trail can show a path back to the top even when the intermediate links were written by hand rather than generated.

The Obsidian 1.13 requirement splits the version line

As of release 4.15.0 the plugin sets minAppVersion to 1.13.0 and uses the newer declarative settings API, so each settings section appears in the global settings search and can be navigated as a page. The legacy imperative display() fallback has been removed.

That leaves users on Obsidian 1.12 with a fixed choice: Breadcrumbs 4.14.2 is the last release supporting 1.12, and fixes for that line are maintained on a separate 1.12-compat branch. The recent release history shows the gap closing quickly. Version 4.22.0 and 4.22.1 both shipped on 2026-10-12, following the 4.22.0-beta.4 release on 2026-09-27, and the last push to the repository was on 2026-10-14.

The practical cost of staying on 4.14.2 is that you stop receiving the settings API work and anything added since. The cost of moving to Obsidian 1.13 is that the settings UI changes shape, and the plugin no longer works on the older app at all. Either way, the plugin version and the Obsidian version have to be treated as one decision rather than two independent upgrades.

Running the plugin from source pulls in Rust, wasm-pack and Bun

Installers do not build anything. Contributors do, and the repository layout explains why the build is heavier than a typical Obsidian plugin. There is a wasm directory, a wasmPlugin.mjs file, an esbuild config, a Svelte config and a vite config, and the package scripts show wasm-pack building for the web target.

The Makefile provides dev, test and build targets, and each one follows the same recipe. It installs wasm-pack globally, points rustup at the stable toolchain, adds the rust-src component for that toolchain, installs dependencies with Bun, builds the WebAssembly part, builds the plugin, and then starts the watch tasks.

Here is the dev target exactly as the Makefile defines it, tabs included, so you can compare it against your own checkout.

dev:
		bun install -g wasm-pack
		cd wasm
		rustup override set stable
		rustup component add rust-src --toolchain stable-x86_64-unknown-linux-gnu
		cd ..
		bun install
		bun run wasm:build || exit 1
		bun run build || exit 1
		bun run dev

Note what that recipe assumes. Rust has to be on the machine, the wasm target has to compile, and the Node ecosystem is driven by Bun rather than npm. The individual package scripts break the work down further, for example the production build running the type check, svelte-check and the esbuild config in sequence.

		"build:esbuild": "tsc -noEmit -skipLibCheck && svelte-check && bun run esbuild.config.mjs production",
		"build": "bun run clean && bun run build:css && bun run build:esbuild",
		"test": "vitest --config vite.config.mjs",

The documentation site at breadcrumbs-docs.michaelpporter.com holds the full setup instructions, and CONTRIBUTING.md is pointed to for development setup and build commands. A separate demo vault repository is published with pre-configured edge fields, example notes and a working graph structure, which is a faster way to see the behaviour before you wire up your own vault.

A bundled WebAssembly engine and a stated no-network policy

Breadcrumbs states that it is fully open source and makes no automatic network requests. It ships a Security Policy for reporting vulnerabilities and a DISCLOSURES.md file that covers a full audit of network requests, the bundled WebAssembly engine and code patterns that are easy to miss.

The WebAssembly piece is not incidental. The Rust code under wasm is compiled with wasm-pack for the web target and then loaded as a plugin asset, and the source tree pairs a TypeScript and Svelte front end with that compiled core. That is the same shape as an embedded query engine, and it explains the Rust and wasm-pack requirements in the build recipe.

What to check before trusting the no-network claim in your own environment is exactly what DISCLOSURES.md is for. A vault plugin that reads every note in your graph has broad reach over your content, and the audit document is where the network, engine and code-pattern claims are set out in full rather than in a summary.

Where typed links stop being the right model

The limitation is in the premise. Breadcrumbs needs relationships that can be typed and, ideally, that are already declared somewhere in the vault. If your notes are a flat pile of linked atoms with no hierarchy, no naming scheme and no consistent frontmatter, there is nothing for the plugin to read, and adding typed links by hand is more work than the built-in graph view ever was.

The distinction the project draws is between showing that two notes link and showing how they relate. If the answer you want is a visual map of every link, Obsidian's own graph already answers it, and it carries no version requirement, no WebAssembly payload and no configuration step.

A second boundary is data ownership. Breadcrumbs infers structure from conventions it recognises, including Dataview queries, so a vault that mixes several incompatible schemes at once can produce a hierarchy that looks coherent in the trail and disagrees with what the author intended in the Matrix view. The plugin cannot ask you which of two parents was meant when a note sits under two naming schemes.

There is also a maintenance history to weigh. The plugin was originally created by SkepticMystic, and since May 2026 it has been maintained by michaelpporter. The repository credits the original creator for the plugin concept and architecture, and lists mProjectsCode, HEmile and michaelpporter for contributions. The licence is MIT, held in LICENSE.md in the repository root, so read that file for the exact terms before shipping it in a redistributed vault template.

Editorial conclusion

Breadcrumbs fits Obsidian users whose notes already encode hierarchy somewhere, in frontmatter properties, folder note names, Dendron style paths, Johnny.Decimal numbering or Dataview queries, and who want that structure visible while writing. It does not fit someone who wants Obsidian's own graph view, since that graph only records that two notes link, and it does not fit vaults still on Obsidian 1.12 unless you stay on Breadcrumbs 4.14.2. Before installing, check the minAppVersion of 1.13.0 against the Obsidian build your team runs, and read DISCLOSURES.md if the bundled WebAssembly engine and the no-network claim matter to your threat model.

Frequently asked questions

Official sources

1. License: MIT
2. michaelpporter/breadcrumbs on GitHub
3. Project website
4. README
5. Releases