Markdown Has No Way to Say Who Said the Quote — Where the Attribution Goes, and What GitHub Deletes

Markdown's > blockquote syntax has no attribution slot. The HTML standard — the WHATWG Living Standard — explicitly requires that the author's name sit outside the <blockquote> element. GitHub's post-render sanitizer deletes the HTML tags that do it correctly. One plain-paragraph pattern survives all 11 renderers tested.¹²³

The Stack Overflow question "Citing the author of a blockquote using Markdown syntax" has accumulated more than 152,000 views since 2010 — with two related questions adding another 32,000 views on top.⁴ The top answer, voted up 300 times, puts the attribution inside the quote block. The HTML standard, verbatim, says that is wrong.

This post is a renderer-tested reference. It covers what Markdown actually does, what the standard requires, where three common habits go wrong, and what the portable pattern looks like across every tool you are likely to use.

What does the > syntax actually create?

Markdown's > prefix creates a <blockquote> element. It has one job: mark a passage as quoted. It carries no built-in attribution field. John Gruber's original 2004 Markdown specification noted the syntax was modelled on email quoting conventions — not on HTML's semantic structure.⁵

The <blockquote> element does accept a cite= attribute — a URL pointing to the source. But the WHATWG Living Standard is explicit about its purpose: the attribute is "primarily intended for private use (e.g., by server-side scripts collecting statistics about a site's use of quotations), not for readers."² No browser renders cite= visibly. It is invisible to every reader and to every Markdown export tool.

That is the full extent of what the > syntax gives you: a quoted passage and an invisible URL slot. Nothing for the speaker's name.

Where the standard says the attribution belongs

The WHATWG HTML Living Standard, §4.4.4, is unambiguous:

"Attribution for the quotation, if any, must be placed outside the blockquote element."¹

The specification gives a worked example. A quote from Aldous Huxley's Brave New World is marked as a <blockquote>. The attribution — a paragraph reading —Aldous Huxley, <cite>Brave New World</cite> — appears as a plain <p> element after the closing </blockquote> tag. The standard's own note explains why: "to clearly relate a quote to its attribution (which is not part of the quote and therefore doesn't belong inside the blockquote itself)."³

MDN Web Docs states this in the same terms: "According to the specification, attribution for the quotation, if any, must be placed outside the <blockquote> element."⁶

The <cite> element used in that example has a strict meaning too. It marks the title of a work — a book, a film, a song. The WHATWG specification states: "A person's name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people's names."⁷ The correct markup is — Author Name, <cite>Book Title</cite>. The person's name is plain text; <cite> wraps only the title.

The portable Markdown equivalent follows the same structure:

> Here is the quoted passage.

— Author Name, *Book Title*

A blank line after the blockquote. The attribution as a plain paragraph. That is the pattern the standard describes, translated into Markdown.

The lazy-continuation trap

The most common mistake looks like this:

> Here is the quoted passage.
— Author Name

No blank line between the blockquote and the attribution line. This looks like it should work. It does not.

CommonMark's specification defines "lazy continuation" for block quotes: a line following a > block, with no > prefix, is treated as a continuation of the previous block quote content — not as a new paragraph outside it.⁸ Gruber's original 2004 specification describes the same behaviour: "Markdown allows you to be lazy and only put the > before the first line of a hard-wrapped paragraph."⁵

The result: without a blank line, the attribution line is absorbed into the quote. The rendered output reads as if the author said both the quoted passage and their own name.

Own receipts tested across 11 rendering settings — GitHub's Markdown API, CommonMark-family parsers, pandoc, Obsidian, markdown-it, and micromark — confirmed this behaviour is universal: the lazy-continuation pattern swallows the attribution line into the quote in 11 of 11 settings.⁹

Add the blank line and the attribution appears outside the quote in 11 of 11 settings.¹⁰

What GitHub deletes — and what it does not

HTML does provide a correct semantic structure for quoted content with attribution: a <figure> element wrapping a <blockquote> and a <figcaption>, with an optional <cite> for the title:

<figure>
  <blockquote cite="https://example.com/source">
    <p>Here is the quoted passage.</p>
  </blockquote>
  <figcaption>— Author Name, <cite>Book Title</cite></figcaption>
</figure>

This is semantically correct and renders correctly in a browser. It does not survive GitHub.

GitHub's post-render sanitizer — the library github/markup uses after converting Markdown to HTML — strips HTML it considers potentially harmful. The sanitizer's own README states: "The HTML is sanitized, aggressively removing things that could harm you and your kin" and that "markup itself does no sanitization."¹¹ The sanitization happens after rendering.

Own receipts sent the <figure>/<blockquote cite=>/<figcaption>/<cite> pattern to GitHub's /markdown API in gfm mode: all three tags — <figure>, <figcaption>, and <cite> — were deleted. The cite= attribute on the <blockquote> was retained, but that attribute is invisible to readers. What remained was the blockquote content and the attribution as a bare, unstyled text run.¹²

This is not GitHub Flavored Markdown's tagfilter extension. The GFM specification's §6.11 lists the nine tags that GFM's tagfilter blocks: <title>, <textarea>, <style>, <xmp>, <iframe>, <noembed>, <noframes>, <script>, and <plaintext>.¹³ <figure>, <figcaption>, and <cite> are not on that list. The deletion is GitHub.com's sanitizer, not the GFM specification.

The same HTML sent through pandoc's gfm→docx pipeline produces an empty document: the quote and attribution both disappear.¹⁴ Two parsers — markdown-it and micromark — in their default configurations print the raw HTML as visible text rather than rendering it, so readers see the angle brackets and tag names.¹⁴

Obsidian's callout — portable only inside Obsidian

Obsidian offers a [!quote] callout type. Its documentation shows the alias cite and explains that text added after the type identifier becomes the callout's title.¹⁵ A note might look like this:

> [!quote] Author Name
> Here is the quoted passage.

Inside Obsidian, this renders as a styled callout with the author's name prominently displayed. Outside Obsidian, it becomes something different. Own receipts sent the same pattern to GitHub's /markdown API: GitHub printed [!quote] Author Name literally inside the <blockquote> element — the callout syntax is opaque to every renderer other than Obsidian itself, in 11 of 11 off-Obsidian settings tested.¹⁶

A similar problem applies to the -- Author Name convention. A double-hyphen before the name is absorbed into the blockquote in every renderer tested — -- is not an em-dash, so the lazy-continuation rule applies and the line stays inside the quote in 11 of 11 settings.¹⁷

The - list-item convention (- Author Name on the line after the quote) performs better: it appears outside the quote as a list item in 9 of 11 CommonMark-family settings. But it is still inconsistent — pandoc's markdown parser treats it as inside the quote in 2 of 2 pandoc settings — and it produces a list item rather than a plain attribution paragraph.¹⁷

The portable pattern — renderer matrix

The table below summarises the five patterns across six common rendering contexts, based on own receipts from a full 11-setting × 12-case matrix run on 2026-11-05.

The blank-line paragraph pattern is the only one that places the attribution outside the quote across all eleven rendering settings. For exportable, portable Markdown, it is the correct choice.

Why attribution accuracy matters

Source memory — the brain's record of where a piece of information came from — is unreliable. Johnson, Hashtroudi and Lindsay's 1993 review in Psychological Bulletin documented the range of ways source judgments can go wrong, including "misattributed familiarity" and "cryptomnesia," where a recalled fact loses its origin entirely.¹⁸

The practical consequence is real. A large cross-national study published in Nature Human Behaviour in 2022, drawing on 10,195 participants across 24 countries, found that statements attributed to a scientist rather than a spiritual figure produced a source-credibility effect across all 24 countries — the effect held regardless of whether participants held religious or non-religious worldviews.¹⁹ Attribution shapes how claims are received. A quote that cannot be traced back loses that effect entirely.

The Stack Overflow corpus illustrates the problem at scale. The second-highest-voted answer on Q2002120 — voted up 129 times — cites "The secret to creativity is knowing how to hide your sources" as an Einstein quote, linking to a quotation aggregator site. Quote Investigator's research traces the earliest known form of this idea to C.E.M. Joad in 1926. The first known attribution to Einstein appeared in a 1989 Usenet post — thirty-four years after Einstein's death. Quote Investigator's conclusion: "There is no substantive evidence that Einstein ever made a remark of this type."²⁰

A note that puts an author attribution inside a blockquote, with no blank line, embeds that attribution in a form that may survive as long as the note does. Getting the syntax right matters.

A note on the reading-note pattern

One earlier MNMNOTE post, Own Your Reading Highlights, teaches a reading-note habit using > "quote" followed by — my note: on the next line, with no blank line between them. That post is about a different practice — capturing your own annotation alongside a quoted passage, not attributing a quotation to its author for a reader.

What the renderer receipts in this post show is that any line immediately after a blockquote with no blank line between them will be absorbed into the quote block by every renderer tested. If you are capturing a note-to-self, that may be an acceptable trade-off — the distinction is a matter of your own reading practice, not the rendered HTML. If you are attributing a quotation to its author for a reader, the blank line is required.

How this works in MNMNOTE

MNMNOTE stores notes as plain Markdown files. The blank-line attribution pattern — > Quote, then a blank line, then — Author, *Work* — is plain text. It round-trips through any export unchanged. No proprietary callout syntax, no tool-specific rendering dependency. What you write is what any renderer sees.

This post's examples are drawn from the WHATWG and MDN documentation examples: Aldous Huxley's Brave New World and Stephen Roberts.¹⁶ They make the structure concrete without requiring you to verify an attribution chain before you know the syntax.

For the blockquote basics this post builds on, Markdown Syntax: The Complete Reference covers the > syntax from the ground up.²¹ For the full provenance-line pattern for research notes, Source, Read: How to Mark Provenance in a Note shows how to build attribution into a consistent note-taking habit.²²

Frequently Asked Questions

How do I add an author to a blockquote in Markdown?

Markdown has no built-in attribution syntax. The portable pattern is a blank line after the blockquote, then a plain paragraph with the attribution: — Author Name, *Work Title*. The blank line is required — without it, the line is absorbed into the quote in every common renderer. The HTML standard requires the attribution outside the <blockquote> element.¹

How do I cite a blockquote in Markdown?

Use a blank line after the > block, then — Author, *Work* as a plain paragraph. The <figure>/<figcaption> HTML structure is semantically correct but GitHub's sanitizer strips those tags — leaving the attribution as an unstyled bare text run. The plain-paragraph pattern is safer and consistent across all renderers tested.

Why does my blockquote attribution appear inside the quote?

The most common cause is a missing blank line. If the attribution line immediately follows the > block with no blank line between them, it is treated as a lazy continuation of the blockquote by every CommonMark-compliant renderer. Add a blank line between the closing > line and the attribution paragraph.

Does <figure>/<figcaption> work for Markdown blockquote attribution?

It is semantically correct HTML, but GitHub's post-render sanitizer removes the <figure>, <figcaption>, and <cite> tags. pandoc's gfm→docx pipeline produces an empty document when these tags are present. The plain-paragraph pattern is more portable.

What does the cite= attribute on a blockquote do?

The WHATWG specification describes cite= as "primarily intended for private use (e.g., by server-side scripts collecting statistics about a site's use of quotations), not for readers."² No browser renders it visibly. GitHub's sanitizer preserves the attribute on the <blockquote> element but it is invisible to every reader.

Does GFM delete <figure> and <figcaption> tags?

No. GitHub Flavored Markdown's tagfilter extension lists nine specific tags it blocks: <title>, <textarea>, <style>, <xmp>, <iframe>, <noembed>, <noframes>, <script>, and <plaintext>.¹³ <figure>, <figcaption>, and <cite> are not on that list. The deletion is performed by GitHub.com's post-render sanitizer, not by the GFM specification.

Does Obsidian's [!quote] callout work for attributing quotes?

Inside Obsidian, yes — > [!quote] Author Name renders with the name as the callout title. Outside Obsidian, every other renderer tested prints [!quote] Author Name literally inside the blockquote element. If your notes may be read in any renderer other than Obsidian, the blank-line paragraph pattern is the safer choice.

The blank line is not an aesthetic preference — it is the difference between an attribution and a continuation. The standard has been clear about this for years. The renderers have been enforcing it since the beginning. The pattern is one line of whitespace away.

Stored locally on your own device as plain Markdown, notes that follow this pattern need no special tool to stay readable — that is what mnmnote.com is built around.

References