Property Organizer
approvedby vkostyanetsky
Keep frontmatter properties in a custom order. - This plugin has not been manually reviewed by Obsidian staff.
Property Organizer
An Obsidian plugin that keeps the properties of your YAML frontmatter in the order you chose. You describe the order per folder, and the plugin rewrites the property order of matching notes — values, names and note content stay exactly as they were.
Sorting runs on demand through two commands, and — if you turn the setting on — once when the vault is opened. Notes are never sorted behind your back when they are created, edited, renamed or moved.
Example
A template for the Projects folder:
type, status, created, modified, tags
Before:
---
tags:
- work
created: 2026-08-03
summary: Quarterly report
type: project
status: active
---
After:
---
type: project
status: active
created: 2026-08-03
tags:
- work
summary: Quarterly report
---
type, status and created move to the front in template order. modified is not in the note, so it is ignored unless Create missing properties is on. tags is listed and moves up; summary is not listed and keeps its place after the listed ones.
Folder matching
- A template applies to every Markdown note directly in its folder and in any subfolder. A template for
ProjectscoversProjects/note.mdandProjects/Test/note.md. - Matching respects path segments:
Projectsdoes not matchProjects-old/note.md. - An empty folder path means the vault root, is equal to
/, and matches every Markdown note. Use it as a general fallback. - Folder paths are normalized by Obsidian, so
/Projects/,ProjectsandProjects//are the same folder. - Notes that no template matches are left alone.
Template priority
Templates are checked from top to bottom, and the first matching template wins. Later templates are not applied to the same note. Put the most specific folders above the general ones:
| # | Folder | Properties |
|---|---|---|
| 1 | Projects/Archive | type, archived, created |
| 2 | Projects | type, status, created |
| 3 | (empty) | created, tags |
With that list, Projects/Archive/note.md uses the first template only, Projects/note.md the second, and everything else the third.
Property lists
Property names are entered as a comma-separated list, in the order you want them written:
type, status, created, modified, tags
- Leading and trailing spaces are removed.
- Empty entries are ignored, so
type,, status,is fine. - If a name is repeated, only its first occurrence counts.
- Names are case-sensitive and are never rewritten:
Typeandtypeare two different properties.
Sorting rules
- Properties listed in the selected template come first, in template order.
- Every other existing property follows, keeping its original relative order, unless Unlisted properties removes it.
- Values, property names and their casing are never changed.
- Content after the frontmatter is never touched.
- If the frontmatter is already in the required order, the file is not written again.
- If a note has no frontmatter and Create missing properties is off, nothing happens.
Frontmatter is rewritten through Obsidian's own API, so YAML formatting (indentation, quoting, comments) can be normalized by Obsidian. Property values are preserved.
Create missing properties
A global setting, off by default.
-
Off — only properties that already exist in a note are sorted. Template properties missing from the note are ignored.
-
On — every property of the matching template is created if the note does not have it, using an empty value:
property:The required order is applied afterwards.
Property types are left to Obsidian: the plugin never assigns or changes a property type. If a name already has a vault-level type, Obsidian applies it on its own.
Unlisted properties
A global setting that decides what happens to the frontmatter properties of a matched note that the matching template does not list. It applies to both commands and to the automatic run, and only to notes a template matches — notes without a template are never touched.
| Value | What happens |
|---|---|
| Keep all (default) | Nothing is removed. Unlisted properties follow the listed ones, keeping their relative order. |
| Remove if empty | Unlisted properties with an empty value are removed; filled ones are kept and follow the listed ones. |
| Remove all | Every unlisted property is removed. After the run, the frontmatter contains only the properties of the template. |
A value counts as empty when it is:
- an Obsidian property without a value (
null); - an empty string, or a string of spaces only;
- an empty list;
- an empty map.
false, 0 and dates are values, not empty properties.
Properties listed in the template are never removed, even when they are empty. Removal happens before missing properties are created, so a template property removed as empty is not the same thing: it is simply kept.
For a note matched by a template, the order of operations is:
- The template is selected by the usual folder rules.
- Unlisted properties are handled as Unlisted properties says.
- Missing template properties are created if Create missing properties is on.
- The remaining properties are sorted in template order.
Removing properties is a destructive change, so keep the default until you are sure the templates list every property you want to keep — a fallback template for the vault root with an empty property list plus Remove all would strip the frontmatter of every note in the vault.
Commands
| Command | What it does |
|---|---|
| Sort properties in all notes | Processes every Markdown note matched by a template. Notes outside the configured folders are not processed. Shows a summary notice: 3 notes updated, 12 unchanged, 40 skipped, 0 errors. |
| Sort properties in current note | Processes only the note of the active Markdown view. The command is unavailable when the active view is not a Markdown note. |
In the summary, skipped counts notes that were not processed at all: no template matched them, or they have no frontmatter while Create missing properties is off.
The current note command reports what happened:
No matching template for the current note.Properties are already organized.Properties sorted.
Process all notes on vault startup
A global setting, off by default: the plugin processes notes only when you run a command.
- Off — nothing happens when the vault is opened.
- On — every Markdown note matched by a template is processed once the vault has finished loading.
The commands work the same way whatever the setting is: turning it off never disables them.
The setting is read when the vault is loaded, so switching it on takes effect the next time you open the vault. Use Sort properties in all notes to process the vault right away.
Automatic run
When Process all notes on vault startup is on, the automatic run happens once per vault load: after the workspace is ready and after the metadata cache has finished its initial build, without blocking the interface. Writes made by the plugin do not start it again.
Enabling, disabling or hot-reloading the plugin after the vault has finished loading does not trigger a batch run — use the commands instead.
After an automatic run, a notice appears only if notes were updated or errors occurred.
Settings
- Process all notes on vault startup — described above. Off by default.
- Create missing properties — described above.
- Unlisted properties — described above. A dropdown with Keep all, Remove if empty and Remove all.
- Folder templates — an ordered list. Each row holds a folder field, with vault folder suggestions, and a comma-separated property list. Rows are reordered and deleted with the controls Obsidian renders for the list, and Add template appends a new row. Changes are saved automatically.
The settings are built from declarative definitions, so they are found by the search in Settings.
Installation
The plugin requires Obsidian 1.13.0 or newer, which is where the declarative settings API it is built on arrived.
The plugin is not published in the community catalog. Install it manually:
- Build it (see below) or download
main.js,manifest.jsonandstyles.cssfrom a release. - Copy the three files into
<vault>/.obsidian/plugins/property-organizer/. - Reload Obsidian and enable Property Organizer in Settings → Community plugins.
Development
npm install
npm run dev
npm test
npm run lint
npm run build
npm run dev starts a watch build, npm run build type-checks and produces the production main.js.
Source layout:
| File | Responsibility |
|---|---|
src/main.ts | Plugin class, commands, automatic run |
src/settings.ts | Settings types, defaults, loading |
src/settingsTab.ts | Declarative setting definitions |
src/folderSuggest.ts | Folder suggestions |
src/templateMatching.ts | Matching templates against note paths |
src/propertyOrder.ts | Pure property-order computation |
src/organizer.ts | Organizing a single note |
src/batch.ts | Batch processing and summaries |
src/vaultNoteAccess.ts | Vault access through the public API |
Limitations
- Notes are only processed on demand, or once per vault load when Process all notes on vault startup is on; there is no live sorting on create, edit, rename or move.
- A note with invalid YAML frontmatter is skipped, counted as an error, and reported in the developer console. The rest of the batch continues.
- YAML formatting can be normalized by Obsidian when a note is rewritten; comments inside the frontmatter are not guaranteed to survive.
- Folder paths are compared case-sensitively.
- Property types are never created or changed.
Mobile
The plugin is not desktop-only and works on mobile. It uses the public Obsidian API only — no Node.js, Electron or direct file-system access — and notes are processed sequentially, one after another, so a large vault does not flood the device with parallel writes. The controls of the folder template list — add, delete and reorder — are the ones Obsidian renders for a list of settings, so they behave as they do elsewhere in the app; the add affordance, for one, is a button on desktop and a row on mobile. The plugin only renders the two fields inside a row.
Credits
Scaffolded and reviewed with the help of the obsidian-plugin-skill for Claude.
For plugin developers
Search results and similarity scores are powered by semantic analysis of your plugin's README. If your plugin isn't appearing for searches you'd expect, try updating your README to clearly describe your plugin's purpose, features, and use cases.