Link Tooltip

Link Tooltip is a lightweight Obsidian plugin that shows where a hovered link points, in Live Preview and source mode.

A tooltip appears for any link that hides its destination behind a label: every Markdown link [label](destination) — an external URL or an internal note path — and aliased wikilinks [[target|alias]]. Bare links already show their destination as text (a raw URL, or an unaliased [[Note]]), so by default they get no tooltip. Optionally, internal links can show the file they point to in the vault (e.g. Projects/2026/Note.md), which gives unaliased wikilinks a tooltip too when their folder isn't visible.

Obsidian already shows native browser-style tooltips for real <a href> elements in Reading mode, so Reading mode is intentionally out of scope. This plugin targets the editor, where links are rendered by CodeMirror as spans and the destination is not available as an href attribute.

What it does

• Registers a CodeMirror 6 extension for editor views.
• Detects hover on rendered Markdown links and wikilinks in Live Preview and source mode.
• Recovers the hovered link's destination from CodeMirror's syntax tree, not from hidden DOM spans. Internal links show their target as written, or optionally the vault file it resolves to.
• Skips tooltips that would only repeat what the link already shows, unless you turn that check off.
• Shows the destination in a small floating tooltip near the cursor.
• Persists its settings with Obsidian's loadData() / saveData() plugin data APIs.

Settings

• Show tooltips for external links — reveal the destination URL of a hovered external link. On by default.
• Show tooltips for internal links — reveal the target of a hovered internal link or aliased wikilink. On by default.
• Show full path for internal links — show the file each internal link points to in the vault (e.g. Projects/2026/Note.md#Heading) instead of the target as written. Also adds tooltips to links without an alias when their path isn't already visible. A link to a note that doesn't exist shows its target with "not created yet". Off by default; shown while internal tooltips are on.
• Show tooltips for links that already show their destination — also show the tooltip when it would only repeat what the link shows: raw URLs, links without an alias, and links whose label matches their destination. Off by default.
• Tooltip delay — milliseconds to wait after hovering a link before the tooltip appears, from 0 (immediately) to 1000. 300 by default.
• Debug logging — enable only while troubleshooting hover detection.

Every setting shows up in Obsidian's settings search. Requires Obsidian 1.13 or later.

Install into a vault

For local testing, use the deploy script. It builds the plugin, creates the plugin folder if needed, and copies main.js, manifest.json, and styles.css.

npm install
npm run deploy -- --vault "/path/to/Vault"

You can also target the plugin folder directly:

npm run deploy -- --plugin-dir "/path/to/Vault/.obsidian/plugins/link-tooltip"

For repeated local deploys, set OBSIDIAN_VAULT or OBSIDIAN_PLUGIN_DIR in your shell and run npm run deploy.

After deploying, restart Obsidian or reload plugins, then enable Link Tooltip in Obsidian's Community plugins settings.

Troubleshooting

Open Obsidian's developer console with Ctrl+Shift+I on Windows/Linux or Cmd+Option+I on macOS, then check the Console tab.

If the plugin enabled but hover display is not working:

1. Open Settings -> Community plugins -> Link Tooltip.
2. Enable Debug logging.
3. Hover a Markdown link or aliased wikilink in Live Preview or source mode.
4. Filter the console for link-tooltip, with the log level set to include Verbose.

When debug logging is enabled, Obsidian should show a small notice and the console should show console.debug entries prefixed with [link-tooltip]. Chromium hides debug entries at the default log level, so pick Verbose in the console's level dropdown.

The hover diagnostics include the hovered position and the parsed link (its range, destination, kind, and whether it is aliased).

Manual installation

1. Clone or download this repository.
2. Run npm install.
3. Run npm run build.
4. Create a folder named link-tooltip inside your vault's .obsidian/plugins/ directory.
5. Copy main.js, manifest.json, and styles.css into .obsidian/plugins/link-tooltip/.
6. Restart Obsidian or reload plugins.
7. Enable Link Tooltip in Obsidian's Community plugins settings.

Community plugins

Install directly from Obsidian:

1. Open Settings → Community plugins.
2. Make sure Safe mode is off, then click Browse.
3. Search for Link Tooltip and click Install.
4. Enable the plugin.

BRAT (pre-release)

To test a pre-release build with BRAT:

1. Install and enable the BRAT plugin.
2. Run BRAT: Add a beta plugin for testing.
3. Enter brunoribeiro2k/obsidian-link-tooltip.
4. Enable Link Tooltip in Community plugins settings.

Development

Install dependencies once with npm install, then use the npm scripts below. A Makefile wraps them (make lists the targets), and adds make open to open the generated test vault in Obsidian (the first run registers the vault, which needs Obsidian closed).

• npm run dev — esbuild in watch mode (rebuilds main.js on change, inline sourcemaps).
• npm run build — the done-gate: typecheck (tsc), lint (eslint), then the production bundle.
• npm run lint — ESLint on its own, with the official eslint-plugin-obsidianmd rules the community review applies.
• npm test — the node --test unit tests (isExternalUrl, repeatsVisibleText).
• npm run setup-vault — build, then generate the gitignored test-vault/ from the committed fixtures with the plugin deployed and enabled. Open it in Obsidian to verify hover detection, which has no automated coverage (it needs a live editor).
• npm run deploy -- --vault "/path/to/Vault" — build and copy the plugin into a vault for local testing.

Work on a feature branch (or directly on a release branch) and open PRs against main. CI runs lint, build, and tests on every pull request.

Releasing

Releases are PR-driven, and tagging plus the GitHub release draft are automated — you only prepare the version bump.

1. From a clean, up-to-date main (git checkout main && git pull --ff-only), run npm run release -- <patch|minor|major>. It refuses to run anywhere but the tip of origin/main, so the release carries exactly what was merged. This bumps the version (manifest.json, package.json, versions.json) without creating a git tag, lands it on a release/<version> branch, commits, pushes, and opens a PR to main. If you've already created a release branch for this version with a descriptive suffix (e.g. release/1.0.0-first-final) at that same commit, run the command from that branch and it's kept as-is rather than switched to the bare release/<version>.
2. Review and merge the PR into main.
3. On that merge, the release workflow detects the new version, builds, attests build provenance, pushes the matching tag (no v prefix), and creates a draft GitHub release with main.js, manifest.json, and styles.css attached. It links the draft from a comment on the merge commit and from the workflow run summary.
4. Review the draft's notes and publish it. Publishing makes the assets downloadable; the Obsidian community directory picks up the new version on its next review.

The workflow is the sole creator of git tags (so a tag always points at the merged main commit), which is why npm version is configured never to tag here (git-tag-version=false in .npmrc).