How wikilinks and backlinks work in plain markdown

A wikilink is a link to another note, written as that note’s name inside double square brackets, like [[Project Atlas]]. You type it straight into the markdown file and it stays there as those exact characters. A notes app reads the brackets and turns them into something clickable, pointing at the file whose name matches what is inside.

A backlink is the same connection read backwards. If your Monday meeting note contains [[Project Atlas]], that meeting note is a backlink of Project Atlas. Nothing is written into Project Atlas to record it. Backlinks are worked out by scanning your notes for links that resolve to the one you care about, so the list always reflects what the files say right now.

Wikilink syntax

Wikilinks are not part of standard markdown, so the exact rules belong to whichever app reads them. The forms below are the ones you will meet most often, with what Jotura does about each.

What you type	What it means	What Jotura does
[[Project Atlas]]	The note named Project Atlas.md	Resolves, wherever the file sits in the vault
[[Project Atlas|the Atlas work]]	The same note, with an alias after the pipe	Resolves on the name before the pipe. The editor shows the link as you typed it, alias and all
[[Project Atlas#Risks]]	The same note, jumping to a heading	No. The desktop app reads the hash as part of the name. The jotura command-line tool ignores anchors and counts the link
[[work/Project Atlas]]	That exact path	No. The desktop app matches filenames only. The command-line tool does match paths
[[Project Atlas.md]]	The same note, extension written out	No, not in the desktop app. The command-line tool accepts either form

Write bare names. [[Project Atlas]] works everywhere in Jotura, and other markdown apps handle it too.

How a link finds its note

The desktop app resolves a wikilink in two steps. First it looks for a note whose filename, minus the .md, matches what you wrote, ignoring capitals. Folders play no part, so [[today]] matches today.md wherever it lives.

If nothing matches exactly, the app falls back to a fuzzy match and opens the note whose name your text most closely resembles. So [[standup]] opens Daily Standup Notes.md without you naming the file properly.

That is useful, and it has a sharp edge. A wikilink that matches nothing exactly does not fail. It quietly opens the nearest fuzzy match, which can be an unrelated note.

Two notes sharing a filename are a related problem. The app picks the one earliest in alphabetical path order and you cannot point at the other, so keep note names distinct.

What the editor shows you

Jotura tints a wikilink in the accent color when a note with that exact filename exists, and amber when none does. That tint is a filename check only, so a link carrying a folder path, an extension, or a #heading shows amber even when the note it names is sitting right there.

Amber does not promise the click will fail either, because clicking runs the fuzzy step and the tint does not. Read it as “no note is named exactly this”, which is still the signal you want.

Backlinks are computed, never stored

Because backlinks are derived from the text, there is no index file to corrupt and nothing to rebuild. Your vault stays an ordinary folder of .md files, and every link travels with it to another machine or another editor.

The cost is that something has to read the notes each time you ask. Jotura does that reading in its command-line tool, not in a panel in the desktop app. If a permanent backlinks sidebar is what you want, Obsidian and Logseq both have one and Jotura does not.

Any text search gives you a rough version, run from inside the vault:

rg -n "\[\[Project Atlas(\||#|\]\])" .

That finds most wikilinks. It misses folder-qualified ones and standard markdown links to the same file, and it cannot tell you which links are dead.

Listing links from the command line

Jotura ships a command-line tool called jotura alongside the desktop app. Two commands cover both directions:

jotura backlinks "work/Project Atlas.md"
jotura links "work/Project Atlas.md"

backlinks prints every note that links to the target, one hit per line, with the path, line number, and the line of text holding the link. links goes the other way, listing a note’s outgoing links and the file each resolves to, or (unresolved) when nothing matches. Both take --limit N, and --json gives structured output.

These commands are more forgiving than the editor, and they also count standard markdown links whose target ends in .md or another text extension. A link written without the extension, like [the plan](work/Project Atlas), is not counted.

Fixing links after a rename

Moving a note is safe when its links use bare names. Renaming is not. Change Project Atlas.md to Atlas Program.md and every [[Project Atlas]] stops pointing where you meant.

The two surfaces fail differently. jotura links reports those links as unresolved. The desktop editor may fuzzy match some other note and open it with no warning, which is why you fix stale links rather than leave them.

List the referrers first, then rename, then rewrite each one:

jotura backlinks "Project Atlas.md" --json
jotura rename "Project Atlas.md" "Atlas Program.md"
jotura edit "meetings/2026-08-24.md" \
  --replace "[[Project Atlas]]" --with "[[Atlas Program]]"

Past a handful of referrers, loop the --json output into a script and run one edit per hit. Every edit writes atomically, leaves YAML frontmatter untouched, and insists on a unique match, so it fails loudly instead of changing the wrong line. Add --dry-run to preview. That is why the Jotura CLI is the interface to reach for on scripted changes.

Wikilinks or standard markdown links?

	Wikilink	Markdown link
Written as	[[Project Atlas]]	[Project Atlas](work/Project Atlas.md)
Survives moving the file	Yes, when it uses the bare filename	No, the path goes stale
Renders outside a notes app	No, most renderers show the raw brackets	Yes, it is standard markdown
Needs the folder path	No	Yes

Use wikilinks inside your vault, where a notes app does the reading. Use markdown links when the file will be read somewhere else, such as a README on a code host. Mixing both is fine, and jotura backlinks counts both.

Building the habit

Link when you first mention something, not in a tidy-up session later. A backlink list is only worth opening when it is complete, and you will never go back. If you keep daily notes, linking each entry to the project or person it concerns is usually enough structure on its own.

Resist linking everything. A note referenced from two hundred places tells you nothing when you list its backlinks. A project note with nine meeting notes pointing at it tells you the whole story. Aim for a few hub notes that everything else points toward.

Two limits are worth naming. Jotura has no graph view and no plugins to add one, so if you want a picture of your vault as a web of dots, another app will serve you better. What it offers instead is the link commands above plus on-device semantic search, which matches by meaning rather than exact words.

Jotura does open an existing Obsidian vault as it is, with every wikilink byte for byte identical in the file. Embeds like ![[Note]] and block references are kept as plain text rather than rendered.

Wikilinks cost nothing to adopt, because they are only text. The vault you build this way opens in any editor, which means the habit outlives whichever app you happen to be writing in today.