disparatedan77 downloadsVisualise and navigate a family tree built from person notes in your vault.
An Obsidian plugin for building, visualising, and exporting a family tree stored as Markdown notes in your vault.
Arbor grew out of a personal project to easily visualise my own family history. It is not designed to be a canonically correct genealogical tool — it is optimised for practical, everyday use by someone who wants to keep family records in Obsidian and share them with non-technical family members. (And hopefully, to look pretty). If you have similar motivations, it may suit you well.


main.js, manifest.json, and styles.css from the latest release<your vault>/.obsidian/plugins/arbor-family-tree/An example family tree using the Tudor dynasty is included in the example/People/ folder of this repository. Copy that folder into your Obsidian vault and open any of the notes to load the tree — Henry VIII's six marriages and three children with different mothers make for a good demonstration of the plugin's layout.
First, create a folder in your vault to hold your person notes (e.g. FamilyTree/People). Person notes must live in a folder — notes in the vault root will not be detected by the plugin.
Then run Arbor Family Tree: Create Person Note from the command palette with any person note active, or with your people folder open. You will be prompted for a first name and family name. Arbor will create a note with the correct frontmatter in the same folder as the active note.
Alternatively, create a note manually in your people folder using the schema below.
Click the tree icon in the ribbon, or run Arbor Family Tree: Open Tree View from the command palette. On first use the tree roots on whichever person note is currently active. After that, the ribbon icon restores the last-viewed person and all toolbar settings automatically.
The default view mode shows blood siblings only, and those connected only by marriage will be omitted. When toggled to include siblings (in-laws) connected by marriage the layout can get complicated and lose clarity for large familes.
Each person is a single Markdown file. The filename can be anything, but Arbor uses the file stem as the person's identifier — the convention is First Last_xxxx.md where xxxx is a short random suffix to keep filenames unique.
---
ar_type: person # required — marks this note as a person record
first_names: # given name(s)
family_name: # surname
sex: # male | female (blank = unknown)
DOB: # year (1923), approximate (~1923, c.1923), or YYYY-MM-DD
DOD: # same formats as DOB
birthplace:
married: [] # list of wikilinks to spouse note stems
father: # wikilink to father's note stem
mother: # wikilink to mother's note stem
---
All fields except ar_type are optional. Arbor will render whatever is present.
Relationships use standard Obsidian wikilinks:
father: "[[John Smith_ab12]]"
mother: "[[Mary Jones_cd34]]"
married:
- "[[Jane Doe_ef56]]"
Arbor supports multiple independent family trees in one vault. Place each tree's person notes under a different top-level folder (e.g. FamilyTree/People and AnotherTree/People). Arbor uses the top-level folder name as the tree's identity and will prompt you to choose if it detects more than one tree.
Run Arbor Family Tree: Export Tree as HTML to generate a standalone HTML file saved to your vault root. The file is fully self-contained — no internet connection required — and can be shared with anyone who has a web browser. Colours are captured from your active Obsidian theme at the moment of export, so the HTML matches exactly what you see in Obsidian. The file includes a ☀ Light / 🌙 Dark toggle so recipients can switch between both colour sets in their browser.
Run Arbor Family Tree: Export Tree as GEDCOM to generate a GEDCOM 5.5.1 .ged file, compatible with genealogy applications such as Gramps. The exporter covers individuals, birth/death dates and places, and family units derived from parent and spouse fields.
This project is intentionally kept simple — it's a personal visualisation tool, not a full genealogical application, and I'd like it to stay that way. PRs that add significant complexity in pursuit of correctness or completeness probably aren't a good fit, but bug fixes, performance improvements, and modest UX enhancements are very welcome.
Please open an issue before starting significant work so we can discuss the approach. All PRs must pass the CI checks (type check, tests, and build) before review. If you are fixing a bug or adding a feature, please include or update tests for the affected pure logic in plugin/src/__tests__/.
This plugin was developed with the assistance of Claude (Anthropic).
MIT — see LICENSE.