Footnotes and Citations in Plain Markdown

You can cite sources in a note you own with one bracket. Write your sentence, drop a marker like [^1] after it, then define the note at the bottom: [^1]: the source. That is the whole footnote on-ramp — no tooling, no account, no manager. The marker and its text stay inside the file as readable plain text.

That single move solves the part of citation most people get wrong: where the reference lives. A footnote written this way is not a row in some app's database. It is characters in a Markdown file you can open, search, copy, and back up forever.

The deeper layer — a real, restyle-on-demand bibliography — keeps every source in a plain-text .bib file and renders it with Pandoc. This post covers both: the zero-tooling footnote first, then the scholarly pipeline, with the honest caveats about where each one breaks.

How do I add a footnote in Markdown?

Add a footnote in two parts. Put a reference marker right after the word it annotates, then write the definition anywhere in the file, usually at the bottom. GitHub documents the exact shape: "You can add footnotes to your content by using this bracket syntax."¹ The renderer collects the definitions, numbers them, and links the marker to the note.

Here is a sentence that needs a source.[^1]
You can label markers anything — numbers or words.[^pandoc]

[^1]: The first source, written as plain text.
[^pandoc]: A second note. The label `pandoc` never appears in the output.

Two rules matter. The label is an identifier, not the printed number — [^pandoc] renders as a superscript "2," not the word. And the identifier is restricted: in Pandoc's words, footnote identifiers "may not contain spaces, tabs, newlines, or the characters ^, [, or ]," and "in the output, footnotes will be numbered sequentially."² You write [^longnote]; the reader sees a tidy number.

The payoff is durability. The note text never leaves the document. Move the file to another machine, another editor, another decade, and the footnote travels with the sentence it belongs to.

Where do footnotes work — and where do they break?

Footnotes are an extension, not part of core Markdown — and that single fact decides where they render. The baseline specification, CommonMark, does not define footnotes at all. Its only mention is historical: some implementers "extended the original Markdown syntax with conventions for footnotes."³ So a footnote is a feature a renderer adds, never a guarantee.

The honest version: footnotes were never in the original. MultiMarkdown's own documentation says so plainly — its author added footnote support "using the syntax proposed by John Gruber," because "unfortunately, he never implemented footnotes in Markdown."⁴ The [^1] convention is a widely adopted afterthought, not a law.

The good news is how widely it was adopted, and how uniformly. The same text[^1] / [^1]: note pattern renders in Pandoc, PHP Markdown Extra, MultiMarkdown, GitHub-Flavored Markdown, and most editors built on them. PHP Markdown Extra describes it the same way everyone else does: a footnote is "a marker in the text that will become a superscript number" plus a definition placed in a list at the end.⁵ One syntax, many renderers.

The trap is assuming everywhere. The clearest gotcha: GitHub renders footnotes in issues, pull requests, and READMEs, but its own docs warn that "footnotes are not supported in wikis."¹ A bare CommonMark renderer will show the literal [^1] instead of a superscript. Test your target before you trust it.

How do I make a real bibliography in Markdown?

Keep your sources in a plain-text .bib file and cite them by key. Pandoc's citation syntax borrows from BibTeX but feels native to Markdown: a citation is a key inside brackets, like [@smith2004]. Multiple sources separate with semicolons — [@doe99; @smith2000; @smith2004] — and Pandoc renders them in your chosen style.⁶ Each key resolves against an entry in your bibliography file.

The key itself is constrained, in Pandoc's words, so it parses cleanly: "the citation key starts with a letter, digit, or _."⁶ A .bib entry that key points to is itself just plain text:

@book{ango2023,
  author    = {Ango, Steph},
  title      = {File over app},
  year       = {2023},
  url        = {https://stephango.com/file-over-app}
}

In your prose you write [@ango2023]. To render it, Pandoc reads the .bib, swaps each key for a formatted citation, and appends a works-cited list:

pandoc paper.md --citeproc --bibliography refs.bib -o paper.pdf

That is the entire mechanism. Your manuscript holds keys; your .bib holds the data; Pandoc joins them at render time. The references are structured plain-text data you own — the same idea as keeping note metadata in readable fields rather than locking it inside an app's database. (We made that argument in full in your notes can be a database without a silo: a .bib is the references version of the same principle.)

Do I have to learn a citation style? (CSL)

No — Pandoc has a sensible default, so the style step is optional until you need a specific one. When --citeproc is set, "pandoc can automatically generate citations and a bibliography in a number of styles."⁶ If you name no style, Pandoc falls back to chicago-author-date.⁶ You can produce a formatted bibliography without ever touching a style file.

When you do need a particular style — APA, MLA, a journal's house format — you point Pandoc at a CSL stylesheet with the --csl option. The historian W. Caleb McDaniel describes the full pair from a practitioner's seat: to turn citations into formatted footnotes, "Pandoc needs both a bibliography file containing all the cited BibTeX entries and a CSL file to tell it which style manual to use."⁷

Both statements are true. The .bib is mandatory; the CSL is simply how you override the default style.

The practical sequence, then, has three rungs you climb only as far as you need:

1. Footnotes — [^1] for any note. Zero tooling.
2. Keyed citations — [@key] against a .bib, rendered by Pandoc in its default style.
3. A named style — add --csl apa.csl (or your journal's) when the format must match exactly.

Most writing never needs rung three. The point is that each rung leaves your sources as readable text, not a query against a vendor's server.

Why keep citations as plain text at all?

Because the reference outlives the tool. The argument is not new, and it is not ours. Chris Krycho, writing about academic Markdown in 2015, named the goal exactly: a single canonical source you can still read whatever operating system or publishing tool comes and goes. Plain text files get him there.

In his words, the aim is "to have a single canonical source for the content, which I will be able to access in the future regardless of what operating system I am using or what publishing systems come and go. Simple plain text files — Markdown — get me there."⁸

The cost of the alternative is concrete. McDaniel learned it the hard way: "When I switched from PC to Mac about six months into working on the thesis, I couldn't use Citation any more, and the only way to take my notes with me was to export them into one, gigantic Rich Text Format file that was impossible to sort in a reasonable way. Never again!"⁹ A proprietary database held his work hostage at the worst possible moment.

The .bib answers that. As McDaniel puts it, "any citation software that interfaces with .bib files (which is most of the ones currently on the market) will be able to accept my notes in the future. At the same time, I am not locked into any proprietary database file formats."⁹ The format is the escape hatch, built in from the start.

This is the same instinct Steph Ango, Obsidian's CEO, calls file over app: "if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read." His one-line version is the whole thesis: "apps are ephemeral, but your files have a chance to last."¹⁰ A citation buried in software is ephemeral. A citation in a file you can read is not.

Common mistakes

Five mistakes turn portable citations back into trapped ones. Each has a one-line fix, and each maps to a claim already made above. Avoiding them is most of the work.

• Assuming footnotes are standard Markdown. They are an extension; CommonMark does not define them.³ A note that renders in your editor may show a literal [^1] in a bare renderer. Fix: confirm your target supports the extension before you rely on it.
• Expecting footnotes in GitHub wikis. They work in issues and READMEs but "are not supported in wikis."¹ Fix: keep footnoted prose in repo files, not the wiki.
• Letting the manager own the canonical copy. If your only .bib lives inside a tool's database and you export "when needed," the database is the source of truth and the file is a stale snapshot. Fix: treat the plain-text .bib as canonical; export into it, edit it directly.
• Reaching for the full pipeline too early. Managing a BibTeX library by hand "is no joke," as Krycho concedes, and Pandoc plus CSL has a real learning curve.⁸ Fix: start at rung one. Footnotes need nothing. Add the .bib only when you have enough sources to justify it.
• Hand-typing keys that won't parse. A citation key must start with a letter, digit, or _.⁶ Fix: pick a simple convention like authorYEAR (krycho2015) and stay consistent.

Reference managers are not the villain here, and the choice is not all-or-nothing. Krycho names Zotero and Mendeley as perfectly viable, precisely because they export to .bib. The contribution is the default: keep the canonical references as plain text you read directly, not a database you export from under duress.

How this works in a plain-text note app

Footnotes and citations are just text, so any editor that keeps your notes as Markdown files keeps them too. In MNMNOTE, a [^1] you type stays in the file the same way the prose does — stored locally on your own device, readable offline, exportable as the same Markdown. Nothing about a footnote depends on the app that showed it.

The references layer follows the same rule. A .bib sits beside your notes as a plain-text file you can open, search, and copy; the citation keys live inside your writing. The relationship between a marker and its source is text, not a database lookup — which is exactly why it survives the move to the next tool.

This is the citation layer of the broader case that your notes are portable until you weld them to an app. It is also the counterpoint to the one seam that does break: see Markdown is portable until you add an image, where footnotes stay inline-with-text while attachments wander off.

Frequently asked questions

How do I cite sources in Markdown?

For a simple note, use a footnote: write your text, add a marker like [^1], then define it at the bottom with [^1]: the source. For a formatted bibliography, keep your references in a plain-text .bib file, cite each with [@key], and render with Pandoc using --citeproc.⁶

Do footnotes work in standard Markdown or CommonMark?

No. CommonMark, the baseline specification, does not define footnotes — it only notes that some implementers "extended the original Markdown syntax with conventions for footnotes."³ Footnotes are a widely supported extension, which is why the same note can render a superscript in one tool and a literal [^1] in another.

How do I add footnotes in Obsidian?

The same way as anywhere else. Type your text, add [^1], and define [^1]: note elsewhere in the file; Obsidian renders it as a superscript. The syntax is the portable extension, not an Obsidian-only feature, so the note text travels if you ever move the file out.

Is a .bib file plain text?

Yes. A .bib file is human-readable plain text that most citation software can read. As McDaniel puts it, "any citation software that interfaces with .bib files (which is most of the ones currently on the market) will be able to accept my notes in the future," without locking you "into any proprietary database file formats."⁹

Do I need to learn a CSL style to make a bibliography?

No. With --citeproc and no named style, Pandoc defaults to chicago-author-date and still produces a full bibliography.⁶ Add a CSL stylesheet with --csl only when you need a specific format like APA or MLA, or a particular journal's house style.

What's the difference between a footnote and a citation here?

A footnote ([^1]) is free-form note text that lives entirely in your document. A citation ([@key]) is a pointer to a structured entry in your .bib file, which Pandoc formats and compiles into a works-cited list. Use footnotes for asides; use keyed citations when you want a real, restyleable bibliography.

Will my footnotes break if I move to another app?

The text never breaks — it is plain characters in the file. What can change is rendering: a renderer without the footnote extension shows the literal [^1] instead of a superscript, and GitHub wikis do not support footnotes at all.¹ The fix is to keep the file as Markdown and check that the new tool supports the extension.

Your scholarship should be readable the day the tool that displayed it is gone. Keep the footnote in the sentence and the bibliography in a file you can open, and it will be — this builds on the plain-text-citations practice documented by Chris Krycho and W. Caleb McDaniel, whose .bib-you-own framing this post follows. To keep yours in plain Markdown you own, there is mnmnote.com.