Property Audit

See every frontmatter property in your vault, then rename, merge or remove one across all of your notes — with a preview first and an undo after.

Obsidian builds its property suggestion list from every key that has ever appeared anywhere in your vault, and gives you no screen that lists them. So a vault that has been going for a while ends up with Author and author, due and due-date, a status that is a string in eleven notes and a list in three, and a dozen keys used by exactly one note each — all of it offered to you every time you add a property, and none of it visible anywhere.

Property Audit is that missing screen, plus the three operations you want once you can see it.

What it does

• Lists every property, with how many notes use it, what kinds of value it holds, and a few real samples. Sorted by how common it is.
• Groups spellings of the same property. Due Date, due_date and due-date fold together; case, spaces, hyphens, underscores, dots and slashes are ignored. Plurals are not folded — tag and tags are genuinely different keys in plenty of vaults, and this tool suggests rather than decides.
• Flags mixed value types. A property that is a date in most notes and free text in a few is what makes a Bases filter or a Dataview query quietly return the wrong rows.
• Flags rarely used properties. These are what clutters the suggestion dropdown.
• Renames a property across every note, keeping the rest of the frontmatter byte-for-byte as you wrote it — quote style, key order, comments, indentation, blank lines, CRLF.
• Merges two properties, with a policy for notes that have both: skip the note, keep the existing value, overwrite it, or combine both into one list.
• Removes a property from every note that has it.
• Undoes any of it. Each operation stores the previous text of every note it changed.

Nothing is written until you have seen what will change

Every operation builds a plan first. The plan knows every note it will touch, and the confirmation tells you how many, how many were skipped and why, and which .base files and Dataview queries also name that property. You then say yes, or you do not.

Renaming a property is the single most destructive thing a plugin can do to a vault of notes. Take a backup before your first run. The undo here is good and it is tested, but it lives in this plugin's own data file, and no undo is a substitute for a copy of your vault.

Install

Not yet in the community directory.

With BRAT (the usual way to run a plugin that is not in the directory): install Obsidian42 - BRAT from Community plugins, run BRAT: Add a beta plugin for testing, and paste https://github.com/theseusbuilds/property-audit. The repository is laid out the way BRAT reads — manifest.json in the root, and each release carries main.js, manifest.json and styles.css as assets — but I have no Obsidian install here, so I have not watched BRAT do it. The manual route below is the one I can check from where I am.

By hand: download main.js, manifest.json and styles.css from the latest release, put them in <your vault>/.obsidian/plugins/property-audit/, and enable the plugin in Settings → Community plugins.

Open the panel from the ribbon (the checklist icon) or the command Property Audit: Open the property panel.

Settings

setting	default	what it changes
Ignored folders	.obsidian/, .trash/, .git/	Notes under these prefixes are never scanned and never edited.
Call a property rare at or below	1 note	The threshold for the "rarely used" section.
Operations kept undoable	10	Each stores the previous text of every note it changed, so this costs disk.

Limits, stated plainly

• It edits the top level of the frontmatter block and nothing else. A key nested inside another key is listed as part of its parent's value and cannot be renamed or removed on its own.
• It only touches a --- block at the very start of a file. An unterminated fence, a --- further down, and multi-document YAML are all left alone rather than guessed at.
• A key repeated twice in one note counts once. That is invalid YAML and Obsidian keeps the first one, so this does too — the panel's numbers agree with the app's.
• It reports references in .base files and Dataview blocks. It does not rewrite them. A rename will break a base or a query that names the old property, and the confirmation says which files those are so you can fix them. Rewriting them is a rewrite across two query grammars, and one that half-works leaves you with some queries fixed, some silently not, and no way to tell which without reading all of them. An honest list beats a clever rewrite you cannot check.
• The reference scan is textual. It looks for the property name as a whole word inside .base files, fenced dataview / dataviewjs blocks, <% … %> Templater lines and field:: inline fields. It will miss a name built up at runtime and it may report a line that happens to use the same word.
• Merging lists rewrites the merged property as a block list (- item on its own lines), even if one side was written inline as [a, b]. The other properties in the file are untouched.
• It makes no network request of any kind, has no account and holds no credentials.

What is tested, and what is not

npm test runs 122 checks. Covered: frontmatter parsing, every rename and remove case above, conflict policies, CRLF and missing-trailing-newline files, quoted keys, comments, the inventory and duplicate grouping, the reference scanner, plan building, and the whole apply → journal → undo sequence against a fake vault — including a write that fails halfway through.

Not covered: the panel itself, and the real Obsidian vault API. The plugin has been built and type-checked but the panel has not been exercised in a running Obsidian, because it was written on a machine with no GUI. If something in the panel misbehaves, that is why, and an issue with what you clicked is genuinely useful.

Licence

See LICENSE. Source-available: use and modify it yourself freely; redistribution and derivative plugins need permission.