How to Add Footnotes in Markdown

Short answer: Markdown footnotes use two parts — a reference like [^1] where the marker should appear, and a definition like [^1]: The note text. elsewhere in the file. GitHub Flavored Markdown supports them; CommonMark does not. The renderer collects the definitions, numbers them in order of first reference, and puts them at the bottom of the document with links back to where each was cited.

Footnotes are the feature that separates markdown-as-a-README-format from markdown-as-a-writing-format. Once you're citing sources, adding asides, or annotating technical claims, you need them — and the syntax is one of the few markdown extensions that's genuinely well designed.

The Syntax

Markdown was created in 2004.[^1]

[^1]: John Gruber, with input from Aaron Swartz.

Two parts:

The reference — [^1] inline in your text, where the marker appears.
The definition — [^1]: text on its own line, starting at the left margin.

The label between ^ and ] is an identifier, not a display number. The renderer ignores it for numbering purposes and assigns numbers in the order the references appear in the document. Write [^99] as your first footnote and it still renders as footnote 1.

Named Footnotes

Numbers are fragile. Insert a note in the middle of a document and every subsequent label is off by one — not in the output, which renumbers automatically, but in the source, where you now can't find anything. Use descriptive labels instead:

The parser follows CommonMark rather than the original spec.[^commonmark]
Tables come from GitHub's extensions.[^gfm]

[^commonmark]: See the CommonMark specification, section on inline elements.
[^gfm]: GitHub Flavored Markdown Spec, section on tables.

Labels can contain letters, digits, hyphens, and underscores. They cannot contain spaces. They're internal — readers never see them, only the generated numbers. This is the same reason people use named reference links instead of numbered ones, and it makes a long document far easier to edit.

Multi-Paragraph Footnotes

A footnote can hold more than a sentence. Indent continuation lines by four spaces:

Here's a claim that needs unpacking.[^detail]

[^detail]: The first paragraph of the note.

    The second paragraph, indented four spaces so the parser knows
    it belongs to the footnote rather than the document body.

    - Lists work too
    - So do code blocks and blockquotes

Four spaces is the threshold here, and it's the same indentation that would otherwise create a code block — see tabs and indentation in markdown for why that number keeps appearing. Under-indent and the paragraph escapes the footnote and lands in your document body.

Long footnotes are usually a signal that the content belongs in the main text or in a collapsible section. If you're writing three paragraphs of setup instructions in a footnote, a collapsible details block is the better container.

Where They Render

You don't place footnotes — the renderer does. Regardless of where the definitions sit in your source file, GFM:

Collects every definition that has a matching reference.
Numbers them by order of first reference in the document.
Renders them in a list at the very bottom of the document, under a horizontal rule.
Turns each marker into a link down to its note.
Adds a return arrow on each note linking back to the marker.

If the same footnote is referenced more than once, you get one entry at the bottom with multiple return arrows.

Definitions are invisible where they sit. You can put them all at the bottom of the file, or immediately under the paragraph that cites them — the output is identical. Keeping each definition near its reference makes editing easier; collecting them at the bottom makes the prose cleaner to read in raw form. Pick one and be consistent.

Unused definitions don't render. A definition with no matching reference is silently dropped. Unmatched references do render — as literal text, so [^5] with no definition appears in your output as the characters [^5]. That asymmetry is worth knowing, because a typo in a label produces visible junk in one direction and silent omission in the other.

Inline Footnotes

Pandoc and Obsidian support an inline form that skips the definition entirely:

This is a claim.^[The supporting detail, written right here.]

Everything between ^[ and ] becomes the footnote. No label to keep track of, no definition to maintain.

It's convenient for short asides, and it is not part of GFM. On GitHub, ^[text] renders as literal text with the caret and brackets visible. Use it only when you know the whole pipeline supports it.

Where Footnotes Work

Platform	`[^1]` footnotes	`^[inline]` footnotes
GitHub (READMEs, issues, discussions)	Yes	No
GitLab	Yes	No
Obsidian	Yes	Yes
Pandoc	Yes	Yes
MkDocs / Python-Markdown	With the `footnotes` extension	No
Hugo	Yes (Goldmark, on by default)	No
Jekyll / Kramdown	Yes	No
Static sites using remark	With `remark-gfm`	No
Reddit / Discord / Slack	No	No
Strict CommonMark	No	No
OpenMark	Yes	No

Footnotes were added to GitHub Flavored Markdown well after tables and task lists, which is why older tools and some markdown libraries still don't have them. If your renderer is based on remark, footnotes come with the remark-gfm plugin rather than the core parser — a common reason they work on GitHub and then break on a project's documentation site.

OpenMark renders footnotes in Document view with working markers and return links, so you can check the numbering before publishing rather than after.

When Footnotes Aren't Supported

If your target renderer doesn't do footnotes, the options are all worse, but some are less bad than others.

A References section. Number your citations manually in the text and list them under a heading at the bottom. No links, no automatic numbering, but it's portable to literally every renderer including plain text.

Manual anchors. Raw HTML gives you the linking behavior by hand:

Some claim.<sup><a href="#fn1" id="ref1">1</a></sup>

<p id="fn1">1. The note text. <a href="#ref1">back</a></p>

This works anywhere raw HTML is allowed, including GitHub, but you're maintaining every number and every anchor ID yourself. It's tolerable for two or three notes and miserable beyond that. See subscript and superscript in markdown for the <sup> details.

Parentheses. For an aside rather than a citation, a parenthetical is often what the sentence wanted. Footnotes carry a cost for the reader — every marker is an invitation to jump somewhere else. Use them for sources and genuine tangents, not for every qualification.

For longer-form work where footnotes matter, markdown for technical writing covers document structure, cross-references, and the other conventions that keep a large markdown document navigable. Markdown extensions: GFM and MDX explains which of these features come from which spec.

Download OpenMark → — $9.99, one-time, native macOS. Footnotes, tables, task lists, math, and diagrams rendered live while you write.