Supercharged Links: styling Obsidian links from note metadata

Links that carry information about their target

Supercharged Links is an Obsidian plugin that styles the links in your vault based on note metadata such as tags or YAML frontmatter properties. You can add colors, emoji or other styles to links automatically, and the stated effect is that links become more visually appealing and easier to find.

The use case the project description gives is specific and good. When your notes represent something, a paper, a location, a person, a day of the week, those notes should stand out. Another use is to give notes with a particular tag a loud color. The point is not decoration, it is that the visual feedback helps you find the right note again quickly, which in a vault of thousands of notes is a real navigation problem.

The plugin is written in TypeScript, distributed as an Obsidian community plugin, and MIT licensed. The repository carries a manifest.json and versions.json, the standard Obsidian plugin metadata, alongside main.ts and main.js, a rollup.config.js, a styles.css, an eslint.config.mjs and a data.json.

The architecture is worth spelling out because it explains an unusual dependency. The plugin does not own the styling. It decides which links match which metadata, and it exposes that as data attributes on the link element. The Style Settings plugin, maintained separately, is where you actually pick the colors, and Supercharged Links pushes a style definition into it. That division is why the install instructions list two plugins rather than one.

The two-plugin install, and the three-step workflow

Installation is short. Install and enable the Supercharged Links plugin in Obsidian, then install and enable the Style Settings plugin. The second one is not optional, and the project notes explain why once you have seen the mechanism: Supercharged Links determines what to style, Style Settings determines how it looks.

The workflow is three steps, and the order matters.

First, in the Supercharged Links settings, create a new selector for the attribute you want to style. Second, choose the type of selector, which is Tag, Attribute or Path, and enter the value you want to match. Third, in the Style Settings plugin settings, set up the style for the selected attribute, such as changing the text color or the background color, or adding an emoji.

The three selector types are the whole matching vocabulary. A Tag selector matches a tag on the target note. An Attribute selector matches a frontmatter property, and specifically matches on the property's value. A Path selector matches on the note's path, which includes its name, its folders and its extension, so you can target a folder such as dailies or a file extension.

Path matching has its own mode, and the documentation is explicit about which to pick. If you want to style every note in a folder called dailies, you should select Contains value rather than Exact match, because an exact match against a full path would only hit one specific file.

There is a fourth thing to configure that is easy to miss, because it lives in a different place from the selectors. The plugin has a Target Attributes for Styling option, and the frontmatter attribute you want to match on has to be listed there before any attribute selector will fire. Set the option to include status, for instance, and only then can an attribute selector look for status.

A worked example with a person, a tag and a status

The example workflow in the project documentation follows a note about a colleague named Jim, with frontmatter and a tag:

---
status: call soon
age: 42
---

Jim is one of my colleagues

#person

The goal is that links to people get a blue background, and that people you need to call get a telephone emoji in front of the link.

The configuration follows the three-step workflow, with the attribute named in Target Attributes for Styling first, then a Tag selector with the value person, then an Attribute selector for status with the value call soon. The documentation notes that the attribute selector also picks up inline fields called status from DataView, so the same rule covers both frontmatter and inline Dataview fields.

Then comes the part that trips people up, and the documentation calls it important. Under Style options you should enable only the Add content before link option for that rule, because otherwise the style would override the one from the tag selector. In other words, the plugin's own rules can collide, and the fix is to scope each rule's style options rather than to apply everything everywhere. This is a small detail with a disproportionate effect on the result.

The styling itself is then done in Style Settings. For the person tag you set a white text color, enable the background and pick a blue one. For the call soon status you paste the emoji into the Prepend text field. There is no scripting and no CSS for the basic case; the emoji and the colors are entered in the Style Settings interface.

What the plugin actually changes in the DOM

The advanced route is CSS, and the documentation explains it by showing the HTML before and after. Without the plugin, an internal link to a note looks like this in the rendered page:

<a data-href="Jim" href="Jim" class="internal-link" target="_blank" rel="noopener">Jim</a>

That element carries nothing about the contents of Jim.md, so there is nothing to style against. The plugin adds two extra properties to the anchor element, data-link-status and data-link-tags. The documentation is careful to note that these are prefixed with data-link so that they will not conflict with other attributes in Obsidian.

So the whole mechanism is: read metadata from the target note, write it onto the link element as data attributes, and let CSS or Style Settings react to those attributes. A CSS snippet can then target data-link-tags or data-link-status directly. You write the snippet under Settings, Appearance, CSS Snippets in Obsidian, style the links based on those data attributes, save the file and enable the snippet.

The prefix decision is what makes this safe to extend. Because the attributes are namespaced to the plugin, a theme or another plugin that also writes data attributes will not collide with them, which is a small but real robustness property for something that runs inside every link in a vault.

The alternative to all of this is manual CSS targeting by vault path, but the plugin's approach means the styling follows the note rather than the folder structure, so moving a note does not break its appearance.

Where the styling shows up, and which plugins are covered

Coverage is stated in two tiers. Live preview, source view, reading mode and the file browser are fully supported in core Obsidian, and the project notes list the core plugins that work alongside: Backlinks, including backlinks in edit mode, Outgoing links, Bases, Search, Starred files, Recent files, Quick Switcher and Bookmarks.

The community plugin list is longer: Breadcrumbs from version 4 onwards, Graph Analysis, Recent files, Quick Switcher++, Another Quick Switcher, Dataview for inline fields, Folder notes, Similar notes and Omnisearch.

The Dataview entry is the important one for anyone using this plugin seriously, and it works in both directions. The attribute selector also matches inline Dataview fields, so a rule written against a frontmatter property can also fire on an inline field. And the plugin set includes a separate Meta plugin that generates project structure metadata as JSON for use by LLM and AI tools, plus a Skills plugin that installs AI skill files for Claude Code, Copilot and OpenCode.

The plugin's own build pipeline is a standard TypeScript and Rollup setup, with the dev script running rollup in watch mode, a production build script, a typecheck script running tsc with no emit, a lint script and a release script based on standard-version. The dev dependencies include the Obsidian API package and the Dataview package, and the CodeMirror packages, which are what make the source view and live preview support possible rather than an afterthought.

Where Supercharged Links is the wrong choice

The first limitation is that the plugin can only style what already exists in your notes. Every rule needs a tag, a frontmatter property or a path to match on, so a vault whose notes are unstructured text gets nothing out of it. And because matching is per target note, a link to a note that has no matching metadata stays plain, which means an inconsistent vault produces inconsistent styling.

The second is the hard dependency on Style Settings. That is a separate community plugin, separately installed, separately updated, and the two versions have to agree on the interface between them. A plugin that cannot be used alone is a plugin whose breakage is out of your hands.

The third is the rule collision problem the documentation hints at with the Add content before link advice. When several selectors match the same link, which style wins depends on how each rule's options are scoped, and getting that wrong means a rule silently overrides another. That is a configuration burden that grows with the number of rules, and it is invisible until you notice that a link looks wrong.

The fourth is that this is a presentation layer, not a semantic one. Nothing about the plugin makes the metadata better, and nothing it does would help a reader of a shared or exported note, since the styling lives in the reading application rather than in the file. If your goal is for a note to communicate something to any reader, in any tool, then putting the meaning in the note's content is the durable approach and this plugin is a convenience on top of it.

The fifth is the maintenance picture. The last push was on 2026-09-04, with version 0.14.0 released on the same day, and the preceding releases were 0.13.10 in December 2025 and 0.13.9 a few days before that. The 0.x version number means the plugin's API can still change between minor releases, which is normal for Obsidian plugins and worth remembering before you build a large rule set on top of it.

Editorial conclusion

Supercharged Links fits an Obsidian vault where a bare link tells you nothing about its target and you want a person, a paper or a daily note to look different at a glance, since the plugin turns metadata into visual cues without touching your notes. It is the wrong choice for a vault where links should look uniform, for anyone unwilling to depend on a second community plugin, or for a workflow that needs styling applied consistently across machines without manual setup. Before installing, decide whether your vault actually carries the metadata the plugin reads, since frontmatter values and tags have to exist before there is anything to style, and note that the plugin was last pushed on 2026-09-04 with version 0.14.0 released the same day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mdelobelle/obsidian_supercharged_links on GitHub
4. README
5. Releases