Markdown Footnotes: Syntax and Platform Guide

September 15, 2026 · 7 min read

Markdown Footnotes: Syntax and Platform Support

Markdown footnotes let you add references, citations, and additional context without cluttering the main text. The syntax uses [^1] for the reference marker and [^1]: text for the footnote content. Footnotes are supported on GitHub, Obsidian, Pandoc, and several static site generators, though they are not part of the core CommonMark specification.

How Do Footnotes Work in Markdown?

A footnote has two parts: a reference in the text and a definition at the bottom. The reference is a caret inside square brackets, and the definition starts with the same identifier followed by a colon.

This claim needs a source[^1].

[^1]: Smith, J. (2025). "Research Findings." Journal of Examples, 42(3), 100-115.

When rendered, the [^1] becomes a superscript number that links to the footnote at the bottom of the page. The footnote text also includes a backlink arrow that returns the reader to where they were in the text.

You can place footnote definitions anywhere in the document. Most renderers collect them and display them at the bottom regardless of where you write the definition. We recommend putting definitions at the end of the document for cleaner source files.

Markdown Footnote Syntax

Basic Numbered Footnotes

Markdown was created by John Gruber[^1] with help from Aaron Swartz[^2].

[^1]: John Gruber published the original Markdown specification in 2004.
[^2]: Aaron Swartz gave feedback on the syntax while it was being designed.

Named Footnotes

You can use descriptive names instead of numbers:

The CommonMark specification[^commonmark] defines the standard.

[^commonmark]: CommonMark is a strongly defined specification of Markdown, version 0.31 as of 2024.

Named footnotes make your source easier to read and maintain. The renderer still displays them as sequential numbers.

Multi-Line Footnotes

Indent continuation lines to create footnotes that span multiple lines or paragraphs:

This topic is complex[^details].

[^details]: The full explanation requires context.

    This second paragraph is part of the same footnote.

    - Even lists work inside footnotes
    - Just keep the indentation consistent

The exact indentation is parser-specific. GitHub's and Obsidian's docs both show continuation lines prefixed with 2 spaces, while Pandoc documents 4-space indentation for additional paragraphs inside a footnote. When in doubt, indent by 4 spaces and check the rendered result on your target platform.

Inline Footnotes (Pandoc and Obsidian)

Pandoc and Obsidian support a shorthand inline syntax that defines the footnote right where you use it:

This is a statement^[This is the inline footnote text.] that continues normally.

This syntax is convenient for short notes, but support is limited: Pandoc renders it, Obsidian renders it in reading view only (not in Live Preview), and GitHub does not support it.

Platform Support for Markdown Footnotes

Footnotes are not part of CommonMark 0.31. Support comes from platform-specific extensions:

PlatformFootnote SupportNotes
GitHubYes (since 2021)Issues, PRs, discussions, and Markdown files; not in wikis
ObsidianYesNamed, multi-line, and inline footnotes (inline in reading view)
PandocYesFull support including inline footnotes
Jekyll (kramdown)YesSupported by the default kramdown parser
HugoYesSupported via Goldmark parser (default since Hugo 0.60)
VS Code PreviewExtension neededUse the Markdown Footnotes extension
Our EditorNoThe preview uses marked without a footnote extension, so the syntax shows as plain text
Standard CommonMarkNoNot in the base specification
RedditNoNo footnote support
SlackNoNot a Markdown renderer

GitHub's footnote support was a major addition in late 2021 (the GitHub markdown cheat sheet lists its other extensions). Before that, GitHub users had to use manual link-based workarounds. The current implementation handles numbered references, named references, and multi-paragraph footnotes.

When Should You Use Footnotes?

Footnotes work best for content that supports your main argument but would break the reading flow if included inline. Common use cases include:

Academic citations. Link to papers, books, and sources without interrupting the reader. Footnotes are standard in academic writing, and markdown makes them easy to manage.

Technical caveats. Add edge-case details or version-specific notes that only some readers need. "This works on Linux[^1]" keeps the main text clean while providing the exception.

Legal disclaimers. Add required notices without cluttering the primary content.

Historical context. Provide background information that enriches the content for curious readers but is not essential to the main point.

Avoid using footnotes for critical information. If a reader needs the content to understand your point, put it in the main text. Footnotes should always be supplementary.

Common Mistakes with Markdown Footnotes

Mistake 1: Forgetting the caret character.

[1]: This is a link reference, not a footnote.
[^1]: This is a footnote (note the caret ^).

Without the ^, markdown treats the bracket notation as a link reference definition.

Mistake 2: Mismatched identifiers.

This text has a reference[^note].

[^footnote]: This definition has a different ID and won't match.

The identifier inside the brackets must match exactly between the reference and the definition.

Mistake 3: Using footnotes on platforms that do not support them.

If your target is Reddit, Slack, or a basic CommonMark renderer, footnotes will display as raw text. Check your platform before relying on them. Use parenthetical notes or inline links as alternatives.

See What an Unsupported Renderer Does

Our editor's preview is built on marked, which does not implement the footnote extension, so it shows footnote syntax exactly as written. That makes it a quick way to see what readers on Reddit, Slack, or any plain CommonMark renderer would get. Draft the file here, then render it on GitHub, in Obsidian, or with Pandoc for the numbered output:

Footnote Example

Markdown was created in 2004[^1]. It has since become the standard for developer documentation[^docs].

More Content

The CommonMark spec[^2] standardized the syntax.

[^1]: John Gruber published the original spec on his blog, Daring Fireball.
[^docs]: GitHub, GitLab, and Bitbucket all support markdown natively.
[^2]: CommonMark version 0.31, released in 2024.

54 words385 characters11 lines
Markdown

Frequently Asked Questions

Summary

Markdown footnotes provide a clean way to add citations, caveats, and supplementary information using [^id] references and matching definitions. GitHub, Obsidian, and Pandoc support them fully, while CommonMark, Reddit, and Slack do not. Use named identifiers for readability, keep footnote content supplementary, and always check your target platform for support. Draft your document in the editor, then check the footnotes on your target platform, or see all syntax options in the markdown cheat sheet.

Written by the Markdown Editor Online team. Last updated September 2026.