A footnote in Markdown is a numbered reference that links inline text to a note at the bottom of the document. You add an inline marker like [^1] where the reference belongs, then define the note elsewhere with [^1]: note text. Footnotes are an extended feature, not part of core Markdown or CommonMark, so support depends on the flavor.
Markdown footnotes syntax reference
| Goal | Syntax |
|---|---|
| Inline reference | Text with a note.[^1] |
| Note definition | [^1]: The note text. |
| Named reference | Text.[^note] |
| Named definition | [^note]: The note text. |
The reference marker and the definition are linked by a matching label. The label can be a number or a word, and it does not have to match the order the note appears in.
Markdown footnotes key facts
- Add a marker such as
[^1]in the text, then define the note on its own line with[^1]: note text; the matching label links the two. - The label can be a number or a word, and it does not have to appear in the same order the note is defined.
- Most processors renumber the rendered notes in the order the markers appear in the text, so readers always see sequential numbers.
- Footnotes are not part of CommonMark or original Markdown; Markdown Extra, MultiMarkdown, and Pandoc support them, and GitHub added them in 2021.
- A footnote can hold multiple paragraphs, a list, or a code block if you indent the continuation lines, usually by four spaces.
- Footnotes compile to a superscript link in the text and an ordered list of notes at the bottom, each with a link back to its reference.
Use footnotes only when the destination supports them
Footnotes are an extension rather than core CommonMark. GitHub, Pandoc, and several documentation systems support them, but labels, back-references, placement, and export behavior can differ.
Use footnotes for supplementary detail that would interrupt the main explanation. Keep essential instructions in the body because some chat apps, converters, and basic renderers show the footnote syntax as plain text. Use stable, descriptive labels in source when a document will be maintained for a long time. Before publishing or exporting, check that every reference has one definition and that the generated return links remain usable.
Basic syntax
To add a footnote, place a marker in your text and write the matching definition on its own line, usually at the end of the document.
Markdown
Here is a sentence with a footnote.[^1]
[^1]: This is the footnote text.
Rendered output
Here is a sentence with a footnote.[^1]
[^1]: This is the footnote text.
HTML output
<p>Here is a sentence with a footnote.<sup id="fnref:1"><a href="#fn:1">1</a></sup></p>
<div class="footnotes">
<ol>
<li id="fn:1">
<p>This is the footnote text. <a href="#fnref:1">↩</a></p>
</li>
</ol>
</div>
The exact HTML, including the id names and the back-reference arrow, varies by processor. The structure is consistent: a superscript link in the text and an ordered list of notes at the bottom, each with a link back to its reference.
Numbered footnotes
The label after the caret can be any number. Numbers do not need to appear in order in the source, and most processors renumber the rendered notes in the order the markers appear in the text.
Markdown
First point.[^2] Second point.[^1]
[^1]: Note for the first label.
[^2]: Note for the second label.
Rendered output
First point.¹ Second point.²
At the bottom of the page, note 1 reads "Note for the second label" and note 2 reads "Note for the first label."
Even though the definitions are written 1 then 2, the rendered note numbers follow the order the markers appear in the text, so the marker that comes first in the text becomes note 1.
Named footnotes
The label can be a word instead of a number. Named labels make the source easier to maintain because you do not have to renumber when you add or remove notes. The rendered output still shows sequential numbers.
Markdown
Markdown was created in 2004.[^history]
[^history]: By John Gruber, with help from Aaron Swartz.
Rendered output
Markdown was created in 2004.[^history]
[^history]: By John Gruber, with help from Aaron Swartz.
The name is only an internal identifier. Readers see a number, not the word you chose.
Multi-paragraph footnotes
A footnote can hold more than one paragraph, a list, or a code block. Indent the continuation lines so they line up under the definition, usually by four spaces.
Markdown
A claim that needs support.[^long]
[^long]: The first paragraph of the note.
A second paragraph, indented to stay inside the note.
- Even a list item
- Another item
Rendered output
A claim that needs support.[^long]
[^long]: The first paragraph of the note.
A second paragraph, indented to stay inside the note.
- Even a list item
- Another item
Without the indentation, the second paragraph falls out of the note and renders as normal body text.
Inline footnotes
Pandoc supports an inline form where the note text sits directly in the marker, so you do not need a separate definition line. This is a Pandoc extension and does not work in most other flavors.
Markdown
Here is an inline note.^[The note text goes right here.]
Rendered output (Pandoc)
The note renders the same as a labeled footnote: a superscript number in the text and the note at the bottom of the document.
Use the labeled form ([^1]) when you want your document to stay portable, since inline footnotes are Pandoc-only.
Reusing a footnote
Some processors let you reference the same note more than once by repeating the marker. Support is inconsistent, so treat it as a nice-to-have rather than something to rely on.
Markdown
The first mention.[^shared] A later mention of the same note.[^shared]
[^shared]: The shared note text.
On processors that support reuse, both markers point to one note, and the note lists back-links to each place it was referenced. On processors that do not, behavior varies, so verify before depending on it.
Flavor differences
Footnotes are an extended feature. They are absent from CommonMark and from John Gruber's original Markdown. Support was added by later flavors, and GitHub added footnotes to its renderer in 2021. The reference-and-definition syntax ([^1] and [^1]:) is broadly compatible across the flavors that support it.
| Flavor | Footnote support | Notes |
|---|---|---|
| CommonMark | No | Not in the spec. Renders [^1] as literal text unless an extension adds footnotes. |
| GitHub Flavored Markdown (GFM) | Partial | Rendered by GitHub since 2021 on repositories, gists, issues, and pull requests, but not part of the formal GFM specification, so it is not guaranteed in other GFM parsers. |
| MultiMarkdown | Yes | Standard [^label] reference and definition syntax. |
| Markdown Extra | Yes | Origin of the widely copied reference-style footnote syntax. |
| Pandoc | Yes | Full support, including multi-paragraph notes and the inline ^[...] form. |
Other platforms (Obsidian, Notion, Reddit)
- Obsidian: supports footnotes with the standard
[^1]reference and[^1]:definition syntax, plus the inline^[note]form. - Notion: does not support Markdown footnote syntax. Pasted
[^1]stays as literal text. - Reddit: does not support footnote syntax. The markers and definitions render as plain text.
For the full comparison of how flavors differ across all elements, see Markdown flavors.
How Markdific renders it
Markdific renders footnotes written with the standard [^1] reference and [^1]: definition syntax as a note list, with a link in the text and a matching note at the bottom of the document.
Because footnotes are flavor-specific, a document that relies on them may render differently in tools that do not support the syntax.
Try it in the Markdific online editor.
Common mistakes and gotchas
- Assuming footnotes are universal. They are an extended feature. In CommonMark and many lightweight renderers,
[^1]shows up as literal text. - Mismatched labels. The reference
[^1]and the definition[^1]:must use the exact same label. A typo leaves the marker unlinked. - Missing the definition. A reference with no matching definition renders as plain text or a broken link, depending on the processor.
- Forgetting to indent multi-paragraph notes. Continuation paragraphs must be indented (usually four spaces) to stay inside the note.
- Space in the label. Labels should not contain spaces. Use a single word or a number.
- Relying on note reuse. Referencing one note from several markers is not supported consistently across renderers. Verify before depending on it.
- Expecting your chosen name to show. Named labels like
[^history]are internal identifiers. Readers see sequential numbers, not the name.
Best practices
- Use named labels (
[^intro],[^source1]) in the source so you do not have to renumber when editing. - Keep all definitions together at the end of the document for easy maintenance.
- Match each reference to exactly one definition and each definition to at least one reference.
- Indent continuation lines in multi-paragraph notes so they stay inside the note.
- Avoid footnotes in content that must render everywhere, since CommonMark and many chat tools do not support them.
- Prefer the labeled form over Pandoc inline footnotes when portability matters.
HTML equivalent
Footnotes compile to a superscript link in the text and an ordered list of notes, typically inside a container element, with each note carrying a back-link to its reference.
Markdown
A statement.[^n]
[^n]: The supporting note.
HTML output
<p>A statement.<sup id="fnref:n"><a href="#fn:n">1</a></sup></p>
<div class="footnotes">
<ol>
<li id="fn:n">
<p>The supporting note. <a href="#fnref:n">↩</a></p>
</li>
</ol>
</div>
FAQ
How do you add a footnote in Markdown?
Place a marker such as [^1] in the text where the reference belongs, then define the note on its own line with [^1]: note text. The marker and the definition are linked by the matching label.
Do footnotes work on GitHub?
Yes. GitHub added footnote support to its renderer in 2021, so [^1] references and [^1]: definitions render as numbered notes on GitHub, gists, issues, and pull requests. They are not part of the formal GFM specification, but GitHub renders them.
Does CommonMark support footnotes?
No. Footnotes are not part of the CommonMark specification. In a plain CommonMark renderer, [^1] appears as literal text unless an extension adds footnote support.
Can a footnote label be a word instead of a number?
Yes. Labels can be numbers or words, so [^note] and [^1] both work. The label is only an internal identifier. Readers always see sequential numbers in the rendered output.
Can a footnote contain multiple paragraphs? Yes, in flavors that support it. Indent the continuation lines, usually by four spaces, so they line up under the definition and stay inside the note.
Do footnote numbers follow the order I write the definitions? No. Most processors number the rendered notes in the order the markers appear in the text, not the order the definitions are written.
What is an inline footnote?
An inline footnote puts the note text directly in the marker using ^[note text], so no separate definition line is needed. It is a Pandoc extension and does not work in most other flavors.
What HTML does a Markdown footnote produce? A superscript link in the text and an ordered list of notes, usually in a container element, with each note carrying a link back to its reference.
Why is my footnote showing as literal text instead of a note?
Either the renderer does not support footnotes, such as core CommonMark, or the reference and definition labels do not match exactly. Check that [^1] and [^1]: use the same label and that your tool supports the extension.
Can you reference the same footnote more than once in Markdown? Some processors let you repeat the marker so several places point to one note, with back-links to each reference. Support is inconsistent, so verify it in your renderer before relying on it.
Where should you put footnote definitions in a Markdown document? The label links the reference to the definition, so a definition can sit anywhere in the document. By convention you keep all definitions together at the end, which makes them easier to maintain.
How do you write a footnote in Obsidian?
Obsidian supports the standard [^1] reference with a matching [^1]: definition, and also the Pandoc-style inline form ^[note text] that needs no separate definition line.
Sources and compatibility references
Use these primary references for syntax rules. Renderer behaviour can still vary by version and configuration, so preview important documents in their final destination.
Related pages
- Markdown documentation hub
- Links in Markdown
- Automatic links
- Definition lists
- Heading IDs
- Markdown flavors compared
