Obsidian Meta Bind: making frontmatter editable from inside the note

The problem is editing metadata in two places

Meta Bind is a plugin for Obsidian to make notes interactive with inline input fields, metadata displays, and buttons, and the description of what it does is short enough to hold in your head. It allows you to create input and view fields inside your notes, and those input and view fields can then be bound to frontmatter properties, which keeps them in sync with those frontmatter properties. The stated effect is that this allows you to edit and view your frontmatter properties inside your notes.

That is the whole idea, and it addresses a real friction in Obsidian. If a note has a status, a due date, a set of tags-as-properties, and a rating, then filling those in means opening the properties panel, and the note itself usually also wants to mention them. With the values in the body and in the frontmatter, the two can drift.

The example in the README makes the design concrete. You can create a toggle inside your note that is bound to a frontmatter property named done, with the simple inline code block INPUT[toggle:done]. When you click the toggle, the done property switches between true and false.

One line of inline code, and a checkbox in the middle of a sentence that is also a real property. That is a much better interface than a properties panel for a checklist, and it is the case the plugin is built around.

The project is GPL-3.0 licensed, written in TypeScript, the author is Moritz Jung, and the last push to the repository was on 2026-08-22. The recent releases are 1.5.1 from 2026-06-16, 1.5.0 from 2026-06-08, and a canary build, 1.5.1-canary.20260802T140138, from 2026-08-02.

The three kinds of field, and the syntax that ties them to properties

Three primitive types are named in the description, and they are the three verbs of the plugin: an input field is for editing, a view field is for displaying, and a button is for triggering an action.

The binding syntax is the small part. The toggle example, INPUT[toggle:done], shows the shape: a kind keyword, a colon, and a property name. The same shape covers the other cases, with a different keyword for a view field and a different one for a button, and the property name on the right of the colon referring to the frontmatter key.

Because the binding is by property name rather than by a copy of the value, the field and the frontmatter cannot disagree. Change the property in the properties panel and the inline field follows, and click the inline toggle and the property changes. That is the sync guarantee, and it is why the plugin exists rather than being a templating trick.

Checking the property names against your vault's existing frontmatter before you write a hundred bindings is the sensible precaution.

The plugin also provides an offline FAQ and Help page, accessible via a command or from the plugin's settings page, so the reference travels with the plugin rather than requiring a connection.

Installing from the marketplace, and the canary path

The recommended installation is through the Obsidian Marketplace, and the steps are the standard community plugin flow.

Open Settings and then Community plugins in your vault, click the Browse button in the Community plugins section, search for Meta Bind, and select it, then click Install first and then Enable.

The second route exists for the canary releases, and it uses BRAT, the plugin that installs a plugin from a GitHub repository. You install and enable the BRAT plugin, run the BRAT: Plugins: Add a beta plugin for testing command, enter the repository URL into the text field, and click Add Plugin.

That second route is how you get the canary builds, which is the pattern the repository already uses. There are two manifests at the top level, manifest.json and manifest-beta.json, and the release history includes a canary version alongside the stable ones. A canary is built from a commit rather than a tag, so the beta manifest and the beta install path belong together.

A Bun monorepo, and a check script that has to pass

The contributor setup is the most specific part of the documentation, and it is unusual in a way that says something about the project.

The plugin uses Bun instead of Node.js and NPM to manage dependencies. To install the dependencies you run bun install and bun run pack:i in the root directory of the project.

The script names are the interesting part. bun run dev builds the plugin in dev mode and watches for changes, and the plugin builds directly into the example vault inside this repository. bun run build builds the plugin in production mode, and the plugin builds into the root of the repo. bun run test runs the tests. bun run check checks for formatting, linting and type errors, and runs the tests, and bun run check:fix fixes formatting and linting errors, checks for type errors, and runs the tests. The check script should run successfully before creating a pull request.

The package manifest shows what the check actually covers, and it is more than a single linter. The check target chains format:check, typecheck, svelte-check, lint, and test. The typecheck is tsc with noEmit and skipLibCheck, the lint is eslint with --max-warnings=0 over the packages source, the format is prettier with the Svelte plugin, and the test script is bun test with browser and development conditions and a LOG_TESTS flag.

The conditions flags matter, because they are how the test suite runs in a simulated browser rather than in Node, which is what an Obsidian plugin needs since it depends on the Obsidian API. The happy-dom global registrator in the dev dependencies is what provides that environment.

The build is vite, the UI is Svelte, and the top level has a packages/ directory, an exampleVault/ directory, and a svelte.config.mjs. The example vault is the development target, which is a good pattern for an Obsidian plugin, since it lets a contributor open a real vault and click on the thing they just changed.

The release automation and the plugin manifest

The release process is automated, and the mechanism is visible in the manifest.

The release script is lemons-automation release, with the automation package in the dev dependencies as @lemons_dev/lemons-obsidian-plugin-automation, and there is a repo-automation.config.json at the top level that configures it. The versioning is tracked in a versions.json file, and the CHANGELOG.md is committed alongside, so the version history is in the repository rather than only on the releases page.

The two manifest files are the plugin's identity in Obsidian. manifest.json is the stable one and manifest-beta.json is the canary variant, and having both at the top level is what allows the same source tree to be published two ways. The main entry point in the package manifest is main.js, which is the file Obsidian loads.

The eslint configuration is unusually thorough for a plugin, and the plugin names in the dev dependencies say what it enforces. There is eslint-plugin-obsidianmd, eslint-plugin-no-relative-import-paths, eslint-plugin-import-x, eslint-plugin-svelte, and eslint-plugin-only-warn, and the lint script runs eslint with --max-warnings=0.

The package structure in packages/ with a svelte-check step is the shape of a modern Obsidian plugin, and it is a reminder that the Obsidian plugin ecosystem has standardised on this stack.

Editorial conclusion

Adopt Meta Bind if you keep structured data in Obsidian frontmatter and want to fill it in while writing, rather than switching to a properties panel. Do not adopt it if your vault has no frontmatter conventions yet, since the plugin has nothing to bind to until it does. Verify first that the field names you want to bind already exist as properties in your notes.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mProjectsCode/obsidian-meta-bind-plugin on GitHub
3. Project website
4. README
5. Releases