Markdown Blockquote: The Complete Guide (2026)

A markdown blockquote is created by starting a line with > followed by a space. The renderer wraps that line (and any contiguous quoted lines) in a styled <blockquote> element, usually with a left bar and indentation. That's the whole spec — but the moment you nest, mix in code, or move the same text between GitHub and Slack, the edges start to show.

This guide covers the syntax, the four breakages that ship in every markdown writer's career, and the one rule that decides whether you should be using a blockquote at all.

Prefer to watch? Traversy Media's markdown crash course covers blockquotes alongside the rest of the syntax in about ten minutes:

The basic markdown blockquote syntax#

The minimum viable blockquote is one line:

> This is a quoted line.

That renders as:

This is a quoted line.

Two things matter. First, the space between > and the text. Strict CommonMark blockquote specification parsers technically allow zero or one space after the >, but every real-world renderer expects one. Skip it and some parsers will eat the quote.

Second, the blank lines. A blockquote is a block-level element, which means it needs a blank line before and after to separate it from neighboring paragraphs:

Some paragraph above.
 
> The quoted text.
 
Some paragraph below.

Without those blank lines, lazy continuation kicks in and the parser may glue the quote into the previous paragraph. This is the same blank-line discipline that causes the blank-line gotcha that breaks markdown horizontal rules — markdown's block elements are pickier than they look.

For a multi-line quote, prefix every line with > :

> Line one of the quote.
> Line two of the quote.
> Line three of the quote.

Nested blockquotes (quoting a quote)#

Stack greater-than characters to nest. Each > adds a level:

> First level — someone saying something.
>
> > Second level — what they're quoting.
> >
> > > Third level — what *that* person quoted.

The classic use case is an email reply chain:

> > > Are we still on for Thursday?
> >
> > Yes — same Zoom link.
>
> Confirmed, see you then.

Most CommonMark renderers handle arbitrary depth, but readability collapses past three levels. Reddit caps practical nesting at 2-3 levels before the indentation becomes visual noise. Discord behaves similarly.

Blockquotes with other elements#

A blockquote is a container. You can put almost any markdown inside it, as long as every line carries the right number of > prefixes.

Lists inside a blockquote#

> Things to remember:
>
> - Prefix every line with `>`
> - Keep the blank line between paragraph and list
> - Don't mix tabs and spaces

Headings inside a blockquote#

> ### A quoted heading
>
> Followed by quoted body text.

This is rare in practice but valid. Most editorial use cases don't need headings inside quotes.

Emphasis and inline code#

> Run `npm install` first, then **stop the dev server** before retrying.

Inline markdown works exactly as it does outside a blockquote.

Code blocks inside a blockquote#

This is where most people slip. The fence lines, the code lines, and the blank lines between them all need the > prefix:

> Here's the install command:
>
> ```bash
> npm install dokly
> ```
>
> Run it from your project root.

Forget a single > on the fence and the renderer thinks the code block ends — or never started.

Multi-paragraph and multi-line blockquotes#

To put two paragraphs in one blockquote, separate them with a blank quoted line (a lone >):

> First paragraph of the quote.
>
> Second paragraph of the same quote.

The lone > is the trick. A truly blank line ends the blockquote; a line with just > keeps it open.

CommonMark also supports lazy continuation — you can omit the > on continuation lines of the same paragraph, and the parser will still treat them as part of the quote:

> This is the start of a long quote
that wraps onto a second line without an arrow.

Lazy continuation works for paragraphs but breaks when the next line starts a new block (a list, a code fence, another paragraph). Don't rely on it. The portable rule: prefix every line, always.

For a hard line break inside a quote, end the line with two trailing spaces:

> Line one of the quote.  
> Line two, with a hard break above.

How blockquotes render across platforms#

The > syntax is universal. The rendered result is not. Here's the same blockquote across the major platforms:

> The best documentation explains *why*, not just *what*.

A few specifics worth knowing.

GitHub follows the GitHub Flavored Markdown spec and added typed alert blockquotes in 2023. Five types render as styled callouts on github.com:

> [!NOTE]
> Useful information for the reader.
 
> [!WARNING]
> Something to be careful about.

These look great on GitHub but render as plain blockquotes everywhere else, including in most MDX renderers. They're an extension, not part of CommonMark. The GitHub typed alert blockquotes documentation lists all five types.

GitLab supports the same > syntax but uses a different (incompatible) callout extension. Don't expect GitHub alerts to work on GitLab.

Slack parses > for blockquotes, but only at the top level — no nesting. Multi-line quotes need >>> (which has the opposite meaning from CommonMark: in Slack, >>> quotes everything that follows until the end of the message).

Discord matches Slack's behavior closely. Single-line > and multi-line >>> at the start of a message.

MDX treats blockquotes as React components under the hood. The renderer you ship with determines styling, and you can override the blockquote element globally — more on that below. MDX's content model explains how markdown and JSX coexist in the same file.

Common blockquote breakages and how to fix them#

Four mistakes account for the vast majority of "why isn't my blockquote rendering" tickets.

1. Missing space after the >#

>This won't render reliably.

Fix:

> This renders everywhere.

Strict CommonMark allows the no-space version. GFM and most editors don't. Always include the space.

2. No blank line before the blockquote#

A paragraph that ends here.
> The quote that gets glued to the paragraph above.

Fix:

A paragraph that ends here.
 
> The quote, now properly separated.

This is the most common breakage in long documents. When you paste a quote into the middle of a paragraph, the blank line is easy to forget.

3. Broken nesting#

> First level
>> Second level with no space.

The unspaced >> works in most renderers, but the unspaced version after the first > (with no space between them and the next character) breaks in some. Use spaces:

> First level
>
> > Second level, properly nested.

4. Lazy continuation eating a list#

> Things to remember:
- Item one
- Item two

The list lines don't have > prefixes, so the parser stops the blockquote at "Things to remember:" and starts a new list outside the quote. Fix:

> Things to remember:
>
> - Item one
> - Item two

When to use a blockquote vs a callout component#

This is the rule most writers miss: blockquotes are for quoting. They mean "these are someone else's words." Callouts are for emphasis — "pay attention to this."

Mix them up and you train readers to ignore both.

Use a blockquote when:

• You're quoting a customer ("Dokly cut our docs setup from a week to an afternoon.")
• You're excerpting an RFC, a paper, or another doc
• You're showing a snippet of text someone else wrote
• You're displaying a literary epigraph at the top of a post

Use a callout component when:

• You're flagging a tip or warning from yourself
• You're surfacing a gotcha mid-tutorial
• You're highlighting a key takeaway
• You're noting a version-specific behavior

In plain markdown you don't have a choice — there's only >. In MDX you do. Here's the same content as both:

> Always run migrations before deploying to production.
 
<Callout type="warning">
Always run migrations before deploying to production.
</Callout>

The blockquote reads as a quotation from somewhere. The callout reads as a directive from the author. They're not interchangeable, even if they look superficially similar.

Dokly ships a full set of callout types — info, note, tip, warning, caution, success, error, danger — and the same applies to every callout, tab, and step component Dokly ships. If your doc has more than two or three blockquotes that aren't actual quotations, you're using the wrong tool.

Styling blockquotes in CSS and MDX#

The default blockquote styling — a gray left bar with some padding — is fine for most cases. When you want something custom, here are the patterns.

Vanilla CSS#

blockquote {
  border-left: 4px solid #6366f1;
  padding: 0.5rem 1rem;
  margin: 1.5rem 0;
  color: #475569;
  font-style: italic;
}
 
blockquote p:last-child {
  margin-bottom: 0;
}

Tailwind (utility classes via prose)#

If you're using @tailwindcss/typography, blockquotes are styled by the prose class:

<article class="prose prose-slate">
  <blockquote>Quoted text here.</blockquote>
</article>

To customize, extend the typography config:

typography: {
  DEFAULT: {
    css: {
      blockquote: {
        borderLeftColor: '#6366f1',
        fontStyle: 'normal',
        fontWeight: '400',
      },
    },
  },
}

MDX component override#

In MDX you can swap the default blockquote element for your own component:

import { MDXProvider } from "@mdx-js/react";
 
const components = {
  blockquote: (props) => (
    <blockquote className="my-quote" {...props} />
  ),
};
 
export default function App({ children }) {
  return <MDXProvider components={components}>{children}</MDXProvider>;
}

Overriding blockquote once gives you consistent styling across every post — far better than sprinkling custom classes throughout your markdown. This is one of the reasons MDX is the right format for modern docs: you get markdown's readability with React's composability.

Frequently Asked Questions#

What is the markdown syntax for a blockquote?#

Start the line with a greater-than character followed by a space: > Your quoted text here. Every line you want quoted needs its own > at the start. For nested quotes, stack them: >> a reply to a quote. Most renderers require a blank line before and after the blockquote — without it, the quote may merge into the previous paragraph or fail to render at all.

How do I create a nested blockquote in markdown?#

Use multiple greater-than characters: > for the first level, >> for a quote inside a quote, and >>> for a third level. Each level needs a space after the last arrow: >> like this. Some renderers (Reddit, Discord) cap nesting at 2-3 levels in practice. GitHub and most CommonMark renderers handle arbitrary depth, though anything past three levels gets hard to read.

Why isn't my markdown blockquote rendering?#

Four common causes. One: you forgot the space after the > — >text doesn't render in strict CommonMark. Two: there's no blank line between the preceding paragraph and the blockquote, so the parser treats it as a continuation. Three: you mixed tabs and spaces inside a nested quote. Four: you're in a context that doesn't support markdown at all (some Slack input boxes, plain GitHub issue titles).

Can I put code inside a markdown blockquote?#

Yes. Indent the fenced code block with > on every line, including the fence lines and the blank lines inside. Inline code with backticks works without anything special: > Run `npm install` first. Be careful with lazy continuation — if the code block follows the quote without > prefixes, some renderers will pull it out of the quote.

Do blockquotes work the same on GitHub and GitLab?#

Mostly. Both follow GFM for the core > syntax and both support nesting and embedded code. GitHub added typed alert blockquotes in 2023 — > [!NOTE] and > [!WARNING] render as styled callouts on GitHub.com but show as plain quotes everywhere else. GitLab has its own callout syntax that isn't compatible. Stick to standard > quotes for portable markdown.

Should I use a blockquote or a callout in my documentation?#

Use a blockquote when you're literally quoting someone or something — a customer testimonial, a section of an RFC, an excerpt from another doc. Use a callout component when you're flagging a tip, warning, or piece of advice from yourself. Blockquotes signal "this is someone else's words"; callouts signal "pay attention to this." Mixing them up trains readers to ignore both.

Next steps#

If you're tired of fighting markdown rendering quirks across platforms and want a docs setup where blockquotes, callouts, and code blocks just work, try Dokly's documentation platform — free, no credit card.