Property Organizer

approved

by vkostyanetsky

Keep frontmatter properties in a custom order. - This plugin has not been manually reviewed by Obsidian staff.

Updated todayMIT

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 Projects covers Projects/note.md and Projects/Test/note.md.
  • Matching respects path segments: Projects does not match Projects-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/, Projects and Projects// 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:

#FolderProperties
1Projects/Archivetype, archived, created
2Projectstype, 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: Type and type are 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.

ValueWhat happens
Keep all (default)Nothing is removed. Unlisted properties follow the listed ones, keeping their relative order.
Remove if emptyUnlisted properties with an empty value are removed; filled ones are kept and follow the listed ones.
Remove allEvery 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:

  1. The template is selected by the usual folder rules.
  2. Unlisted properties are handled as Unlisted properties says.
  3. Missing template properties are created if Create missing properties is on.
  4. 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

CommandWhat it does
Sort properties in all notesProcesses 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 noteProcesses 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:

  1. Build it (see below) or download main.js, manifest.json and styles.css from a release.
  2. Copy the three files into <vault>/.obsidian/plugins/property-organizer/.
  3. 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:

FileResponsibility
src/main.tsPlugin class, commands, automatic run
src/settings.tsSettings types, defaults, loading
src/settingsTab.tsDeclarative setting definitions
src/folderSuggest.tsFolder suggestions
src/templateMatching.tsMatching templates against note paths
src/propertyOrder.tsPure property-order computation
src/organizer.tsOrganizing a single note
src/batch.tsBatch processing and summaries
src/vaultNoteAccess.tsVault 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.