Blockquotes

A blockquote is a block of text marked as quoted from somewhere else: every line starts with >, usually followed by a space. The renderer wraps it in an HTML <blockquote> element, which browsers show indented and many sites style with a line on the left. The convention comes from email, where replies quote the original message the same way.

The customer wrote:

> Since this morning the portal shows "session expired"
> every time I open my invoices.
<p>The customer wrote:</p>
<blockquote>
<p>Since this morning the portal shows &quot;session expired&quot;
every time I open my invoices.</p>
</blockquote>

In IT work, quotes are useful for exactly this: what someone else said or wrote, kept apart from your own words. A customer's message in a ticket, a sentence from a vendor's advisory, a decision quoted in an issue. Use quotes for quoting, not to make a paragraph stand out: the HTML marks the text as a quotation, and many screen readers announce it as one.

Paragraphs, lists and nested quotes

A blockquote is a container: anything that can appear in a document can appear inside it, as long as each line starts with >. A line with only > separates two paragraphs within the same quote. An extra > starts a quote inside the quote, as in an email thread.

> Power is restored in **Deventer**.
> Some smart meters need a manual reset:
>
> 1. Open the meter cupboard.
> 2. Hold the reset button for five seconds.
>
> > Is this also needed for gas meters?
>
> No, only for electricity meters.
<blockquote>
<p>Power is restored in <strong>Deventer</strong>.
Some smart meters need a manual reset:</p>
<ol>
<li>Open the meter cupboard.</li>
<li>Hold the reset button for five seconds.</li>
</ol>
<blockquote>
<p>Is this also needed for gas meters?</p>
</blockquote>
<p>No, only for electricity meters.</p>
</blockquote>

Lazy continuation and separating quotes

Markdown is forgiving about the > markers. If a paragraph inside a quote continues on the next line, you may leave the > off that line: it still belongs to the quote. This is called lazy continuation. It exists so that text rewrapped by an email program or editor stays inside the quote.

> The planned maintenance on 14 October starts at 22:00
and should be finished by 02:00.
<blockquote>
<p>The planned maintenance on 14 October starts at 22:00
and should be finished by 02:00.</p>
</blockquote>

Laziness only continues a paragraph. A line that starts something new, such as a list item or a heading, ends the quote. In practice it is clearer to write the > on every line.

The flip side: two quotes written directly after each other are one quote. To keep them apart, put a blank line between them, without a > on it.

> Portal login fails for all users.
> Started 08:12, no changes known.

> Billing runs are delayed by about an hour.
<blockquote>
<p>Portal login fails for all users.
Started 08:12, no changes known.</p>
</blockquote>
<blockquote>
<p>Billing runs are delayed by about an hour.</p>
</blockquote>

Quotes as notes and warnings on GitHub

GitHub reuses the blockquote syntax for highlighted notes, called alerts. A quote whose first line is [!NOTE], [!TIP], [!IMPORTANT], [!WARNING] or [!CAUTION] is shown as a colored box with an icon and a title. This is a GitHub extension (since December 2023), not standard Markdown. The renderer on this site does not support it, so the block below is not run and its result is described, not rendered:

> [!WARNING]
> Restarting the portal logs out every customer who is signed in.
A box with a warning icon and the title "Warning", containing:
Restarting the portal logs out every customer who is signed in.

In a renderer without the extension, the same text falls back to an ordinary quote, with the marker shown as text. That is a reasonable fallback:

> [!WARNING]
> Restarting the portal logs out every customer who is signed in.
<blockquote>
<p>[!WARNING]
Restarting the portal logs out every customer who is signed in.</p>
</blockquote>

Older tutorials show > **Note** instead, the syntax of the beta version; it is no longer an alert. See Markdown on GitHub and GitLab for the details and for GitLab's equivalent.

Horizontal rules

A thematic break, usually called a horizontal rule, is a line made of three or more -, * or _ characters (all the same, spaces in between allowed) on a line of its own. It becomes the HTML <hr> element: a change of topic within a document, drawn by browsers as a horizontal line.

Update 09:40: engineers are on site.

---

Update 10:15: power is restored in all areas.

***

Update 11:00: incident closed.
<p>Update 09:40: engineers are on site.</p>
<hr>
<p>Update 10:15: power is restored in all areas.</p>
<hr>
<p>Update 11:00: incident closed.</p>

All three spellings give the same result; pick one (most people use ---) and stick to it. Use rules sparingly. In a long document, headings give structure that readers can navigate and link to; a rule only draws a line.

The trap: a rule that becomes a heading

A line of --- directly below a line of text is not a rule. It is the underline of a setext heading, an older heading style, and turns the text above it into a level-2 heading. The fix is a blank line above the rule, or using ***, which cannot underline a heading.

Status: resolved
---

Status: resolved

---
<h2>Status: resolved</h2>
<p>Status: resolved</p>
<hr>

The same rule explains why YAML front matter, which starts and ends with ---, looks broken in renderers that do not know it; see Front Matter and Metadata.

Escaping with a backslash

Markdown uses ordinary punctuation as syntax, so sometimes it formats text you meant literally: a price list with asterisks, a year at the start of a line, a file name with underscores. A backslash escape solves this: a backslash (\) before a punctuation character tells the renderer to show that character as it is, with no special meaning.

Tariffs marked \* include the green energy surcharge.

1986\. The year the first Kestrel plant opened.

\# is the number sign, not a heading here.

Ticket status \[draft\] means: not sent yet.
<p>Tariffs marked * include the green energy surcharge.</p>
<p>1986. The year the first Kestrel plant opened.</p>
<p># is the number sign, not a heading here.</p>
<p>Ticket status [draft] means: not sent yet.</p>

Without the backslashes, the second line would become a numbered list starting at 1986 and the third a heading. The asterisk in the first line happens to be safe because a space follows it, but escaping it costs nothing and keeps it literal if the sentence is rewritten. Any ASCII punctuation character can be escaped:

! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

A backslash before any other character, such as a letter or a digit, is just a backslash. That is why a Windows path like C:\Temp\logs usually comes through intact, but C:\_archive loses its backslash (escaped underscore), and a double backslash shows as a single one. Put paths in inline code and the problem disappears.

Shell glob: `*.log`, regex: `\d+\.log`, escaped: \*.log
<p>Shell glob: <code>*.log</code>, regex: <code>\d+\.log</code>, escaped: *.log</p>

Entity references

An entity reference writes a character by its HTML name or number: &copy; for ©, &euro; for €, &#35; (decimal) or &#x23; (hexadecimal) for #. Markdown recognizes all named entities of HTML and turns them into the character itself. Most people need them rarely: in a UTF-8 file you can type © or € directly. They are handy for characters that are hard to type or invisible, such as a non-breaking space (&nbsp;).

&copy; 2026 Kestrel Energy &middot; Prices in &euro; incl. VAT

In code it stays literal: `&copy;`
<p>© 2026 Kestrel Energy · Prices in € incl. VAT</p>
<p>In code it stays literal: <code>&amp;copy;</code></p>

A name that is not a real HTML entity, such as &kestrel;, is left as text. A plain &, as in "AT&T", needs no escaping: the renderer writes it as &amp; in the HTML for you.

Angle brackets and placeholders

One character deserves special care: <. Many renderers, GitHub among them, allow raw HTML in Markdown. There, a < followed by a letter starts an HTML tag. A placeholder such as <tenant-id> in running text looks like a tag and disappears from the page. The example below switches raw HTML on (data-md-html), as GitHub does:

Open https://portal.example.com/<tenant-id>/settings

Open `https://portal.example.com/<tenant-id>/settings`

Open https://portal.example.com/\<tenant-id>/settings
<p>Open https://portal.example.com/<tenant-id>/settings</p>
<p>Open <code>https://portal.example.com/&lt;tenant-id&gt;/settings</code></p>
<p>Open https://portal.example.com/&lt;tenant-id&gt;/settings</p>

In the first line the placeholder passed through as a tag, and the browser shows nothing for it. Inline code (second line) is the best fix, because a URL with a placeholder is something the reader will copy and edit; a backslash escape (third line) or &lt; also works. With raw HTML switched off, the default on this site, markdown-it shows all three lines with the angle brackets. Why renderers differ here, and why it matters for security, is the subject of HTML in Markdown and Safety.

When escaping is needed

You do not have to escape every punctuation mark "just in case". A character only needs escaping where it would otherwise start something. The usual places:

Character Starts something when… Escaped
* _ paired around text (an _ inside a word, as in snake_case, is safe), or * at the start of a line followed by a space (a list item) \* \_
# at the start of a line, followed by a space \#
1. 1) a number with a dot or parenthesis starts a line 1\. 1\)
- + > at the start of a line, followed by a space (for >, even without a space) \- \+ \>
[ ] brackets followed by (, or matching a link label \[ \]
` a second backtick follows later in the paragraph \`
< followed by a letter, where raw HTML is allowed \< or &lt;
| inside a table cell \|

When the text is technical (a command, a path, a pattern), put it in backticks instead of escaping it piece by piece. Escapes are for ordinary prose that happens to contain a special character.