obsidian-advanced-uri: driving Obsidian from a link instead of a mouse

What the plugin adds to the plain obsidian:// scheme

Obsidian ships its own URI handler, and Advanced URI is a community plugin that extends it with a dedicated `obsidian://adv-uri` scheme carrying a query string of parameters. The plugin description calls it advanced modes for Obsidian URI, and the README frames the value in one sentence: you can control many different features in Obsidian just by opening a URI, and because a URI is text, it needs no mouse clicks or keyboard input, which makes it suited to automation.

The action list in the README is long enough to show the shape of the thing. You can open files, workspaces, headings, blocks, lines and settings; open a file in a tab, a split, a window, a popover, or silently in the background; switch between reading, source and live preview mode; edit, overwrite, append and prepend files; append or prepend content to a specific heading, block or line; write clipboard content into notes including daily notes; open bookmarks; run search and replace on a file with regular expressions; call Obsidian commands and plugin commands; read, edit and focus frontmatter properties; move between notes by file path, file name, alias, daily note or frontmatter UID; open community plugin pages and settings; and check whether a file exists, update community plugins, or enable and disable plugins.

The last group is the one that separates this from a navigation convenience. Checking existence, updating plugins and toggling plugin state are the operations a script needs in order to make a decision, and Obsidian's own scheme does not offer them.

The query string is the whole interface

Every action is a set of key and value pairs in the query string of the `adv-uri` path. The simplest form opens a note, with the path percent encoded and passed as `filepath`.

obsidian://adv-uri?filepath=Home%20Index%2Ftoday

The encoding matters. A space becomes `%20` and the folder separator becomes `%2F`, which is why the example path reads as a single opaque token rather than as `Home Index/today`. The same scheme carries the vault, the action flags and the payload, and the README's examples show how they compose.

obsidian://adv-uri?vault=<your-vault>&daily=true&clipboard=true&mode=append

That one URI appends whatever is on the system clipboard into today's daily note. `daily=true` targets the daily note rather than a named file, `clipboard=true` takes the content from the clipboard, and `mode=append` decides what happens to it. Changing one value changes the meaning of the whole string, which is the central design decision of the plugin and also its main footgun: there is no schema, no type checking and no completion, just a long list of documented parameters.

The `filepath` value is not the only way to point at a note. The README lists file paths, file names, aliases, daily notes and frontmatter UIDs as the file identifier options, and the alias form is worth noting because it lets a script refer to a note by a name a human would use.

obsidian://adv-uri?vault=<your-vault>&filename=Brain%20Dumps

Installing it from the community plugin list or from a release

There are two installation paths and they differ in how much you verify yourself. The supported route is through Obsidian itself. Open `Settings -> Community plugins`, disable `Restricted mode`, then install the plugin using the URI the README links, which points at the plugin id `obsidian-advanced-uri`. If that link does not resolve, the README gives the fallback: open `Browse community plugins` and search for `Advanced URI`. After installing, you enable the plugin.

The manual route is for a vault you control on a machine where the community list is not convenient, or for a version you want to pin. You download the latest release from GitHub, then move three files into the plugin directory inside your vault.

manifest.json
styles.css
main.js

The destination is `<vault>/.obsidian/plugins/obsidian-advanced-uri`, and after the copy you reload Obsidian, disable `Restricted mode` under `Settings -> Community plugins` and enable `Advanced URI`. The repository layout matches that build output: `manifest.json` and `styles.css` are at the top level, and `esbuild.config.mjs` is the bundler configuration behind them.

A third path exists for developers rather than users. The `package.json` scripts are `dev` for `node esbuild.config.mjs dev`, `build` for `node esbuild.config.mjs production`, `release` for `standard-version`, `format` for `prettier src --check` and `lint` for `eslint.`. The plugin is a TypeScript project, with `obsidian` and `eslint-plugin-obsidianmd` among the dev dependencies and `standard-version` handling the changelog and version bump, which is consistent with the `CHANGELOG.md` and `versions.json` files at the top of the repository.

Writing, search and command calls are where the automation pays off

The read and navigation side of the plugin is the part most people know. The write side is the part that changes how a vault is used, because a URI can put content into a specific place in a note rather than at the top of it.

Appending below a heading in the daily note uses the same `daily` flag plus a `heading` parameter and a `data` parameter carrying the text.

obsidian://adv-uri?vault=<your-vault>&daily=true&heading=Inbox&data=-%20New%20idea&mode=append

Because the target is a heading rather than the file, a script can drop items into a named section of the daily note without the note's own structure being disturbed. The README also lists search and replace on a file including regular expressions, and the calling of Obsidian commands and plugin commands, which turns a URI into a general macro mechanism: you are not limited to what the plugin implements, you can reach any command the app exposes.

That command route is what makes a URI useful for export workflows. The README gives an example that exports a file to PDF by calling the command named Export to PDF through its command id.

obsidian://adv-uri?vault=<your-vault>&filepath=<your-file>&commandid=workspace%3Aexport-pdf

The command id is percent encoded, with the colon as `%3A`. The same command id mechanism reaches plugin commands, so a vault that depends on other community plugins can drive them through the same interface.

Launching a URI from anywhere, including a terminal

The plugin is only as useful as the number of places you can fire a URI from, and the README lists four. You can type one into a browser address bar, use one as a markdown link inside Obsidian, open one from a script or a terminal, and use the plugin's own helper commands to copy generated URIs for files, daily notes, search and replace actions, commands and canvas views.

The markdown link is the form most people meet first, and it is what makes the plugin usable from a note rather than from a shell.

[Open note](obsidian://adv-uri?filepath=Home%20Index%2Ftoday)

The terminal route is the one that matters for scripting. On Linux the README gives the launcher directly.

xdg-open "obsidian://adv-uri?filepath=Home%20Index%2Ftoday"

The quoting is deliberate, because the URI contains characters a shell would otherwise interpret. The browser address bar route is the same string, which means a URI can be embedded in a script, an email, a chat message or a calendar reminder, and Obsidian will handle it.

The helper commands deserve a note because they remove the need to hand-build a URI. Rather than remembering the parameter names for a daily note or a search and replace action, you can ask the plugin to generate the URI and copy it, then paste that into whatever you were going to automate.

The parameter reference lives off the repository

This is the practical weakness of the project, and it is a documentation shape rather than a code problem. The README is an index of what the plugin can do, with each item linking into a documentation site hosted at publish.obsidian.md. The overview itself ends with a pointer to the documentation for a detailed explanation, and the installation and usage sections repeat the same pattern.

So the parameter names, the encoding rules and the exact semantics of each action are not in the repository. A `docs/` directory does exist at the top level of the project, but the README does not describe what it holds, and the authoritative reference for the reader is the published site.

That matters for anyone building on the plugin. You cannot clone the repository and read the full parameter set offline, and you cannot rely on the README to settle a question about what a flag does in a corner case. The `openmode=silent` parameter illustrates the point: the README shows the URI for opening a file silently without focusing it, but the full set of open modes, which are tab, split, window, popover and silent, is described in the documentation rather than in the repository text.

The same applies to the identifier system. The README links to a page on file identifiers for the details of path, name, alias, daily note and frontmatter UID, and a separate page for the frontmatter UID mechanism that produces links which keep working after notes are renamed. Those are the two behaviours a scripting user is most likely to depend on, and both are documented away from the code.

Where the plugin stops, and what it costs to depend on it

Two limits are visible in the repository itself. The first is that every capability goes through a URI string, so there is no structured API to call from TypeScript. A script that wants a result back, rather than a side effect, has a problem: the plugin does provide an existence check, with `exists=true` on a `filepath`, but the README documents no general return value channel for arbitrary actions. The check example is the whole of it.

obsidian://adv-uri?vault=<your-vault>&filepath=my-file&exists=true

The second is the dependency on Obsidian itself. The plugin only acts when Obsidian is running and registered for the scheme, so a script that fires a URI at a machine where Obsidian is closed has no effect, and there is no documented queueing or retry behaviour.

There is also a versioning question worth settling early. The release history is short and recent: 2.0.0 on 2026-07-25, 2.1.0 and 2.2.0 both on 2026-09-23, with the last push to the repository on 2026-09-23 as well. The plugin is MIT licensed, and the package is a normal community plugin with `obsidian` as a dev dependency and `obsidian-community-lib` and `uuid` as runtime dependencies, the latter presumably serving the UID identifiers the README mentions for rename-resistant links.

For a plugin this small, the real adoption risk is not the licence or the code, it is that the parameter surface is documented on a site that can change independently of the released version. Pin the plugin version, and check the documentation page that matches it before you build a script on top.

Editorial conclusion

Adopt Advanced URI if you drive Obsidian from scripts, terminal commands, shortcuts or another application, since it turns a text link into navigation, writing, search and command calls that Obsidian's built-in URI scheme does not cover. Do not adopt it if your workflow stays inside the app, because the plugin adds a second URI dialect and the parameter reference lives on publish.obsidian.md rather than in the repository. Before building a script around it, verify the parameters you need against the documentation site, and check that the `filepath` values you pass are percent encoded the way the README shows, because a path with a space breaks the query string.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Vinzent03/obsidian-advanced-uri on GitHub