Markdown Blockquotes: Syntax, Nesting, and Common Mistakes
The complete guide to the markdown blockquote — greater-than syntax, multi-line quotes, lazy continuation, nesting, GitHub alerts, attribution patterns, and the mistakes that split them.
Short answer: A markdown blockquote is a line starting with > followed by a space. Every line of the quote needs its own >, including the blank lines between quoted paragraphs. Nest quotes by stacking markers — >> — and on GitHub you can turn a blockquote into a colored callout by opening it with > [!NOTE].
Blockquotes look like the simplest block in markdown, and for a single line they are. The complications start the moment a quote runs to two paragraphs, contains a list, or sits next to other text. Almost every blockquote bug comes down to one of two rules: which lines need a marker, and what happens when they don't have one.
Basic Syntax
> The best way to predict the future is to invent it.
Renders as:
The best way to predict the future is to invent it.
The space after > is optional in CommonMark — >Quote parses fine — but include it anyway. It's the near-universal convention, some older parsers require it, and it keeps your source readable.
A quote can be as long as you like. Prefix every line:
> This is a longer quotation that runs
> across several lines of source, each one
> carrying its own marker.
All three lines join into a single quoted paragraph, because — as with normal markdown text — single newlines are soft breaks. If you need visible breaks inside the quote, use the same techniques as anywhere else: see markdown line breaks.
Lazy Continuation
You can leave the marker off continuation lines and most parsers will still absorb them into the quote:
> This line has a marker.
This line does not, but it still ends up inside the quote.
This is called lazy continuation, and it's in the CommonMark spec, so it's not a bug. It is, however, a trap.
The problem is that laziness only applies to paragraph continuation. The moment the unmarked line looks like a new block — a heading, a list item, a code fence, a horizontal rule — it ends the quote instead of continuing it:
> Quoted paragraph.
- This list is NOT inside the quote.
You get a blockquote followed by a separate list. Worse, the behavior differs between parsers and between versions, so a document that renders correctly in your editor can render differently on the platform you publish to.
Mark every line. It costs nothing and removes an entire class of bug.
Blank Lines Inside a Quote
To put two paragraphs inside one blockquote, the blank line between them needs a marker of its own:
> First quoted paragraph.
>
> Second quoted paragraph.
Renders as:
First quoted paragraph.
Second quoted paragraph.
Leave the > off that middle line and you get two separate blockquotes with a gap between them:
> First quote.
> Second, entirely separate quote.
Visually this can look almost identical in some themes, which is why it survives review. It's structurally different — two <blockquote> elements instead of one — and it will look wrong in any theme that puts a border or background on quotes.
Nested Blockquotes
Add markers to go deeper:
> Original message.
>
> > Reply to the original.
> >
> > > Reply to the reply.
Renders as:
Original message.
Reply to the original.
Reply to the reply.
You'll see this written as >> without spaces, which parses identically since the space after each marker is optional. > > is easier to read and less likely to confuse a strict parser, so prefer it in anything you'll maintain.
Nesting is how email-style quoting works, and it's how threaded replies render in tools that convert email or chat to markdown. Past three levels it becomes unreadable — consider quoting the relevant fragment instead.
Putting Other Blocks Inside a Quote
A blockquote is a container, so it can hold any block element. The rule stays the same: every line needs a marker.
Lists:
> Requirements before you start:
>
> - A Mac running macOS Tahoe
> - A `.md` file to open
> - Ten seconds
Headings:
> ## Quoted heading
>
> Body text of the quoted section.
Code blocks:
> Run this first:
>
> npm install
>
> Then start the dev server.
Fenced code blocks work inside quotes too, but every line of the fence and its contents needs the > prefix — including the closing fence. Miss one and the code block swallows the rest of your document. Indented code (four spaces after the marker, as above) is often safer inside quotes for that reason.
Tables work as well, with a marker on the header row, the separator row, and every data row. If a quoted table renders as a wall of pipe characters, a missing marker on the separator row is the usual cause. The markdown tables guide covers the separator rules.
GitHub Alerts (Callouts)
GitHub extends blockquote syntax into colored, icon-labeled callouts. Open the quote with a bracketed keyword on its own line:
> [!NOTE]
> Useful information that users should know, even when skimming.
> [!TIP]
> Helpful advice for doing things better or more easily.
> [!IMPORTANT]
> Key information users need to know to achieve their goal.
> [!WARNING]
> Urgent info that needs immediate attention to avoid problems.
> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.
Five types, and the keyword is case-sensitive in practice — write it in caps. The alert marker must be the first line of the blockquote, and GitHub does not allow alerts to be nested inside other elements.
Two caveats:
Everywhere else, they're ordinary blockquotes. A renderer without the extension shows the literal text [!NOTE] as the quote's first line. That's a graceful enough degradation for a README, but check it before using alerts in documentation that also builds to a static site.
Obsidian callouts look similar but aren't identical. Obsidian uses > [!note] with a much larger keyword set (info, todo, question, success, failure, example, and more), supports custom titles on the same line, and supports folding with > [!note]-. Notes written for Obsidian may fall back to plain quotes on GitHub, and vice versa.
Alerts pair well with task lists — a checklist inside a > [!IMPORTANT] block is a common pattern in contribution guides.
Attribution Patterns
Markdown has no native citation syntax for quotes. The common conventions:
> Design is not just what it looks like and feels like. Design is how it works.
>
> — Steve Jobs
The em dash on its own quoted paragraph is the most portable approach. Some writers use a hard break instead so the attribution sits directly under the quote:
> Simplicity is the ultimate sophistication.\
> — Leonardo da Vinci
If you control the CSS, the cite attribute on a blockquote is the semantic option — it's on GitHub's allowlist — though browsers don't display it:
<blockquote cite="https://example.com/source">
<p>Quoted text here.</p>
</blockquote>
Note that markdown syntax inside a raw HTML block is not parsed on GitHub unless you leave a blank line after the opening tag, so write the inner content as HTML or accept plain text.
Common Mistakes
| What you wrote | What happens | Fix |
|---|---|---|
Blank line without > between quoted paragraphs | Two separate blockquotes | Put > on the blank line |
| List directly after a quoted line, no marker | List falls outside the quote | Prefix the list with > |
| Fenced code inside a quote, closing fence unmarked | Code block runs to the end of the document | Mark every line, closing fence included |
>Quote with no space | Works in most parsers, fails in a few | Add the space |
Trailing > on an empty final line | An empty paragraph inside the quote | Delete it |
> [!note] on GitHub | Renders as literal text | Use uppercase: > [!NOTE] |
| Alert marker on the second line of the quote | No callout, just a quote | It must be the first line |
Four-space-indented > | Code block showing a literal > | Remove the indentation |
The four-space one is worth watching for when quoting inside a list item, where you're already indented. Inside a list, a blockquote is indented relative to the item's content column, not the left margin — get that wrong and the quote either becomes code or falls out of the list.
Writing Quotes Without Counting Characters
Every rule above reduces to "does this line have a marker." That's tedious to verify by eye in a long quote, and it's the kind of thing an editor should handle.
OpenMark colors blockquote markers distinctly in Markdown view, so a missing > shows up as a break in the color pattern rather than something you have to hunt for. Document view renders the result — including GitHub-style alerts and nested quotes — so you can confirm the structure before publishing. For everything else in the format, the markdown cheat sheet and markdown for GitHub cover the rest.
Download OpenMark → — $9.99, one-time, native macOS. Blockquotes, nested quotes, and callouts rendered exactly as they'll appear, with the raw source a keystroke away.