Markdown Blockquote: How to Quote Text Without Breaking It

A Markdown blockquote looks like the simplest piece of syntax in the spec, one > at the start of a line, until you try to quote more than a single short paragraph. Multi-paragraph quotes, nested quotes, a blockquote that contains a list or a code block, and quotes that survive a document conversion all break the mental model of "just add a >." This guide covers the syntax that actually works, two gotchas that trip people up, and what happens to quoted text when a Word doc, PDF, or wiki export gets turned into Markdown with file2markdown.

The Quick Answer

Prefix a line with > and a space to turn it into a blockquote:

> This is a quoted sentence.

For a quote spanning multiple lines, prefix every line:

> This is the first line of the quote,
> and this is the second line, still inside it.

To nest a quote inside another quote, stack the markers: >> for one level deep, >>> for two. The space after each > is optional, so > > works too:

> Outer quote.
>
> > Inner, nested quote.

And to put a new paragraph inside the same blockquote (rather than ending it), leave a blank > line between the two paragraphs, a line that still has the > marker but no text after it:

> First paragraph of the quote.
>
> Second paragraph, still inside the same blockquote.

Drop the > on that blank line entirely, and you end the blockquote instead of continuing it. In CommonMark renderers such as GitHub's, the next > line then starts a second, separate blockquote. (John Gruber's original Markdown.pl joins the two into one quote, as the CommonMark spec notes.)

Blockquotes Can Contain Other Block Elements

A blockquote isn't limited to plain text. Headings, lists, and code blocks all work inside one, and each line of the nested element also needs the > prefix:

> ## A heading inside a quote
>
> - A list item
> - Another list item
>
> ```
> a fenced code block, also inside the quote
> ```

This is how you reproduce the common "callout" pattern (a quoted block that contains structured content, not just prose), and it's also what GitHub's alert syntax is built on. Per GitHub's docs, an alert is a blockquote whose first line names one of five types (> [!NOTE], > [!TIP], > [!IMPORTANT], > [!WARNING], > [!CAUTION]), followed by the content as a standard blockquote; GitHub's renderer styles it differently, and alerts can't be nested inside other elements. Alerts are a GitHub feature, not part of the GFM spec. Renderers that don't recognize the alert syntax just show a normal blockquote with the [!NOTE] marker as plain text, so it degrades gracefully.

The Two Gotchas

Lazy continuation. A line immediately following a quoted line, with no blank line and no >, is still treated as part of the blockquote if it would continue the quoted paragraph. The CommonMark spec calls this laziness; it doesn't apply when the unmarked line starts something else, such as a list item, a heading, or a code fence:

> This line starts the quote
and this line has no marker at all

Both lines render as one blockquote. This is convenient when you're typing by hand, but it's a common source of bugs when you're generating Markdown programmatically: a stray unmarked line from a template can silently get pulled into a quote it was never meant to join.

Blockquotes inside tables don't work with > at all. In GitHub Flavored Markdown, table cells hold inline content only, so there's no way to start a new block-level element inside a cell using the standard marker; a > in a cell is shown as a literal character. If you need a quoted aside inside a table cell, the usual workaround is the literal <blockquote> HTML tag, which works wherever the renderer allows raw HTML in cells (GitHub does). It's the same workaround used for forcing line breaks inside table cells.

Why This Matters for AI and RAG Pipelines

A blockquote is one of the few pieces of Markdown syntax that carries semantic meaning beyond layout: it tells a reader (and, more importantly for retrieval pipelines, a chunking or embedding step) that this text is quoted from somewhere else, not the author's own words. That distinction matters when you're building a RAG pipeline over source documents that mix original analysis with cited material, like legal filings, research papers, or meeting notes with quoted decisions. A chunker that treats a blockquote the same as a regular paragraph loses that signal entirely; one that respects block boundaries can keep a multi-paragraph quote intact as a single retrievable unit instead of splitting it mid-citation. We cover the general version of this problem (why block-level structure affects retrieval quality) in Chunking Markdown for Vector Databases and Markdown Tables vs HTML Tables for RAG.

The Real Workflow: What Happens to Quotes During Conversion

Blockquotes rarely get typed by hand in production content; they arrive from somewhere else. Here is how quotes from the common sources come out of file2markdown:

• Word's "Quote" or "Intense Quote" paragraph style is a style name attached to a paragraph, not a semantic block quote. file2markdown converts Word files with Microsoft's MarkItDown, which uses the mammoth library's default style map, and that map has no entry for either quote style. Those paragraphs come out as ordinary paragraphs, with no >.
• HTML <blockquote> elements, in a saved web page or a wiki page exported as HTML, map directly: every line of the quote gets a > prefix, including the blank line between paragraphs, so a multi-paragraph quote stays one blockquote.
• A PDF's indented block is usually just positioned text on a page. Only a tagged PDF can mark a passage as a block quote; file2markdown's PDF parser turns that tag into > lines, while an indented quote in an untagged PDF comes out as a normal paragraph.

If you're converting documents that contain quoted material (Word to Markdown, Confluence pages, or PDF to Markdown), spot-check the output for quoted passages that came out as plain paragraphs, and add the > markers yourself where the distinction matters. For more on why clean block structure matters beyond quotes specifically, see why Markdown works so well for AI.

Frequently Asked Questions

How do I write a blockquote with multiple paragraphs in Markdown?

Put a > on every line, including the blank line between paragraphs: a line with just > and nothing else. In CommonMark renderers such as GitHub's, a truly empty line (no > at all) ends the blockquote instead of continuing it into a second paragraph.

Can I nest blockquotes inside each other?

Yes. Stack the markers: >> for a quote nested one level inside another quote, >>> for two levels deep, and so on. Each level needs its own blank > line (matching its nesting depth) if it spans multiple paragraphs.

Does GitHub Markdown support blockquotes with lists or code blocks inside them?

Yes. Block-level elements (headings, lists, code blocks, and on GitHub even tables) can live inside a blockquote as long as every line of that element also carries the > prefix. GitHub's "alert" callouts (> [!NOTE]) are built on exactly this mechanism.

Why did my blockquotes disappear after converting a Word document or PDF to Markdown?

Usually because the source never marked them as quotes in a way the converter can read. In file2markdown, Word's Quote and Intense Quote styles aren't mapped to blockquotes, so those paragraphs come out as plain text, and an untagged PDF has no quote markup at all; HTML <blockquote> elements do come through as > lines. Checking the converted output against the original document for quoted passages is the fastest way to catch this.