title: CommonMark Spec author: John MacFarlane version: ‘0.31.2’ date: ‘2024-01-28’ license: ‘CC-BY-SA 4.0’ …

Introduction

What is Markdown?

Markdown is a plain text format for writing structured documents, based on conventions for indicating formatting in email and usenet posts. It was developed by John Gruber (with help from Aaron Swartz) and released in 2004 in the form of a syntax description and a Perl script (Markdown.pl) for converting Markdown to HTML. In the next decade, dozens of implementations were developed in many languages. Some extended the original Markdown syntax with conventions for footnotes, tables, and other document elements. Some allowed Markdown documents to be rendered in formats other than HTML. Websites like Reddit, StackOverflow, and GitHub had millions of people using Markdown. And Markdown started to be used beyond the web, to author books, articles, slide shows, letters, and lecture notes.

What distinguishes Markdown from many other lightweight markup syntaxes, which are often easier to write, is its readability. As Gruber writes:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. (https://daringfireball.net/projects/markdown/)

The point can be illustrated by comparing a sample of AsciiDoc with an equivalent sample of Markdown. Here is a sample of AsciiDoc from the AsciiDoc manual:

1. List item one.
+
List item one continued with a second paragraph followed by an
Indented block.
+
.................
$ ls *.sh
$ mv *.sh ~/tmp
.................
+
List item continued with a third paragraph.

2. List item two continued with an open block.
+
--
This paragraph is part of the preceding list item.

a. This list is nested and does not require explicit item
continuation.
+
This paragraph is part of the preceding list item.

b. List item b.

This paragraph belongs to item two of the outer list.
--

And here is the equivalent in Markdown:

1.  List item one.

    List item one continued with a second paragraph followed by an
    Indented block.

        $ ls *.sh
        $ mv *.sh ~/tmp

    List item continued with a third paragraph.

2.  List item two continued with an open block.

    This paragraph is part of the preceding list item.

    1. This list is nested and does not require explicit item continuation.

       This paragraph is part of the preceding list item.

    2. List item b.

    This paragraph belongs to item two of the outer list.

The AsciiDoc version is, arguably, easier to write. You don’t need to worry about indentation. But the Markdown version is much easier to read. The nesting of list items is apparent to the eye in the source, not just in the processed document.

Why is a spec needed?

John Gruber’s canonical description of Markdown’s syntax does not specify the syntax unambiguously. Here are some examples of questions it does not answer:

  1. How much indentation is needed for a sublist? The spec says that continuation paragraphs need to be indented four spaces, but is not fully explicit about sublists. It is natural to think that they, too, must be indented four spaces, but Markdown.pl does not require that. This is hardly a “corner case,” and divergences between implementations on this issue often lead to surprises for users in real documents. (See this comment by John Gruber.)

  2. Is a blank line needed before a block quote or heading? Most implementations do not require the blank line. However, this can lead to unexpected results in hard-wrapped text, and also to ambiguities in parsing (note that some implementations put the heading inside the blockquote, while others do not). (John Gruber has also spoken in favor of requiring the blank lines.)

  3. Is a blank line needed before an indented code block? (Markdown.pl requires it, but this is not mentioned in the documentation, and some implementations do not require it.)

    paragraph
    code?

  4. What is the exact rule for determining when list items get wrapped in <p> tags? Can a list be partially “loose” and partially “tight”? What should we do with a list like this?

    1. one

2. two
3. three

    Or this?

    1.  one
    - a

    - b
2.  two

    (There are some relevant comments by John Gruber here.)

  5. Can list markers be indented? Can ordered list markers be right-aligned?

     8. item 1
 9. item 2
10. item 2a

  6. Is this one list with a thematic break in its second item, or two lists separated by a thematic break?

    * a
* * * * *
* b

  7. When list markers change from numbers to bullets, do we have two lists or one? (The Markdown syntax description suggests two, but the perl scripts and many other implementations produce one.)

    1. fee
2. fie
-  foe
-  fum

  8. What are the precedence rules for the markers of inline structure? For example, is the following a valid link, or does the code span take precedence ?

    [a backtick (`)](/url) and [another backtick (`)](/url).

  9. What are the precedence rules for markers of emphasis and strong emphasis? For example, how should the following be parsed?

    *foo *bar* baz*

  10. What are the precedence rules between block-level and inline-level structure? For example, how should the following be parsed?

    - `a long code span can contain a hyphen like this
  - and it can screw things up`

  11. Can list items include section headings? (Markdown.pl does not allow this, but does allow blockquotes to include headings.)

    - # Heading

  12. Can list items be empty?

    * a
*
* b

  13. Can link references be defined inside block quotes or list items?

    > Blockquote [foo].
>
> [foo]: /url

  14. If there are multiple definitions for the same reference, which takes precedence?

    [foo]: /url1
[foo]: /url2

[foo][]

In the absence of a spec, early implementers consulted Markdown.pl to resolve these ambiguities. But Markdown.pl was quite buggy, and gave manifestly bad results in many cases, so it was not a satisfactory replacement for a spec.

Because there is no unambiguous spec, implementations have diverged considerably. As a result, users are often surprised to find that a document that renders one way on one system (say, a GitHub wiki) renders differently on another (say, converting to docbook using pandoc). To make matters worse, because nothing in Markdown counts as a “syntax error,” the divergence often isn’t discovered right away.

About this document

This document attempts to specify Markdown syntax unambiguously. It contains many examples with side-by-side Markdown and HTML. These are intended to double as conformance tests. An accompanying script spec_tests.py can be used to run the tests against any Markdown program:

python test/spec_tests.py --spec spec.txt --program PROGRAM

Since this document describes how Markdown is to be parsed into an abstract syntax tree, it would have made sense to use an abstract representation of the syntax tree instead of HTML. But HTML is capable of representing the structural distinctions we need to make, and the choice of HTML for the tests makes it possible to run the tests against an implementation without writing an abstract syntax tree renderer.

Note that not every feature of the HTML samples is mandated by the spec. For example, the spec says what counts as a link destination, but it doesn’t mandate that non-ASCII characters in the URL be percent-encoded. To use the automatic tests, implementers will need to provide a renderer that conforms to the expectations of the spec examples (percent-encoding non-ASCII characters in URLs). But a conforming implementation can use a different renderer and may choose not to percent-encode non-ASCII characters in URLs.

This document is generated from a text file, spec.txt, written in Markdown with a small extension for the side-by-side tests. The script tools/makespec.py can be used to convert spec.txt into HTML or CommonMark (which can then be converted into other formats).

In the examples, the → character is used to represent tabs.

Preliminaries

Characters and lines

Any sequence of [characters] is a valid CommonMark document.

A character is a Unicode code point. Although some code points (for example, combining accents) do not correspond to characters in an intuitive sense, all code points count as characters for purposes of this spec.

This spec does not specify an encoding; it thinks of lines as composed of [characters] rather than bytes. A conforming parser may be limited to a certain encoding.

A line is a sequence of zero or more [characters] other than line feed (U+000A) or carriage return (U+000D), followed by a [line ending] or by the end of file.

A line ending is a line feed (U+000A), a carriage return (U+000D) not followed by a line feed, or a carriage return and a following line feed.

A line containing no characters, or a line containing only spaces (U+0020) or tabs (U+0009), is called a blank line.

The following definitions of character classes will be used in this spec:

A Unicode whitespace character is a character in the Unicode Zs general category, or a tab (U+0009), line feed (U+000A), form feed (U+000C), or carriage return (U+000D).

Unicode whitespace is a sequence of one or more [Unicode whitespace characters].

A tab is U+0009.

A space is U+0020.

An ASCII control character is a character between U+0000–1F (both including) or U+007F.

An ASCII punctuation character is !, ", #, $, %, &, ', (, ), *, +, ,, -, ., / (U+0021–2F), :, ;, <, =, >, ?, @ (U+003A–0040), [, \, ], ^, _, ` (U+005B–0060), {, |, }, or ~ (U+007B–007E).

A Unicode punctuation character is a character in the Unicode P (punctuation) or S (symbol) general categories.

Tabs

Tabs in lines are not expanded to [spaces]. However, in contexts where spaces help to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters.

Thus, for example, a tab can be used instead of four spaces in an indented code block. (Note, however, that internal tabs are passed through as literal tabs, not expanded to spaces.)

→foo→baz→→bim
.
<pre><code>foo→baz→→bim
</code></pre>

  →foo→baz→→bim
.
<pre><code>foo→baz→→bim
</code></pre>

    a→a
    ὐ→a
.
<pre><code>a→a
ὐ→a
</code></pre>

In the following example, a continuation paragraph of a list item is indented with a tab; this has exactly the same effect as indentation with four spaces would:

  - foo

→bar
.
<ul>
<li>
<p>foo</p>
<p>bar</p>
</li>
</ul>

- foo

→→bar
.
<ul>
<li>
<p>foo</p>
<pre><code>  bar
</code></pre>
</li>
</ul>

Normally the > that begins a block quote may be followed optionally by a space, which is not considered part of the content. In the following case > is followed by a tab, which is treated as if it were expanded into three spaces. Since one of these spaces is considered part of the delimiter, foo is considered to be indented six spaces inside the block quote context, so we get an indented code block starting with two spaces.

>→→foo
.
<blockquote>
<pre><code>  foo
</code></pre>
</blockquote>

-→→foo
.
<ul>
<li>
<pre><code>  foo
</code></pre>
</li>
</ul>

    foo
→bar
.
<pre><code>foo
bar
</code></pre>

 - foo
   - bar
→ - baz
.
<ul>
<li>foo
<ul>
<li>bar
<ul>
<li>baz</li>
</ul>
</li>
</ul>
</li>
</ul>

#→Foo
.
<h1>Foo</h1>

*→*→*→
.
<hr />

Insecure characters

For security reasons, the Unicode character U+0000 must be replaced with the REPLACEMENT CHARACTER (U+FFFD).

Backslash escapes

Any ASCII punctuation character may be backslash-escaped:

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

Backslashes before other characters are treated as literal backslashes:

\→\A\a\ \3\φ\«
.
<p>\→\A\a\ \3\φ\«</p>

Escaped characters are treated as regular characters and do not have their usual Markdown meanings:

\*not emphasized*
\<br/> not a tag
\[not a link](/foo)
\`not code`
1\. not a list
\* not a list
\# not a heading
\[foo]: /url "not a reference"
\&ouml; not a character entity
.
<p>*not emphasized*
&lt;br/&gt; not a tag
[not a link](/foo)
`not code`
1. not a list
* not a list
# not a heading
[foo]: /url &quot;not a reference&quot;
&amp;ouml; not a character entity</p>

If a backslash is itself escaped, the following character is not:

\\*emphasis*
.
<p>\<em>emphasis</em></p>

A backslash at the end of the line is a [hard line break]:

foo\
bar
.
<p>foo<br />
bar</p>

Backslash escapes do not work in code blocks, code spans, autolinks, or raw HTML:

`` \[\` ``
.
<p><code>\[\`</code></p>

    \[\]
.
<pre><code>\[\]
</code></pre>

~~~
\[\]
~~~
.
<pre><code>\[\]
</code></pre>

<https://example.com?find=\*>
.
<p><a href="https://example.com?find=%5C*">https://example.com?find=\*</a></p>

<a href="/bar\/)">
.
<a href="/bar\/)">

But they work in all other contexts, including URLs and link titles, link references, and [info strings] in [fenced code blocks]:

[foo](/bar\* "ti\*tle")
.
<p><a href="/bar*" title="ti*tle">foo</a></p>

[foo]

[foo]: /bar\* "ti\*tle"
.
<p><a href="/bar*" title="ti*tle">foo</a></p>

``` foo\+bar
foo
```
.
<pre><code class="language-foo+bar">foo
</code></pre>

Entity and numeric character references

Valid HTML entity references and numeric character references can be used in place of the corresponding Unicode character, with the following exceptions:

  • Entity and character references are not recognized in code blocks and code spans.

  • Entity and character references cannot stand in place of special characters that define structural elements in CommonMark. For example, although &#42; can be used in place of a literal * character, &#42; cannot replace * in emphasis delimiters, bullet list markers, or thematic breaks.

Conforming CommonMark parsers need not store information about whether a particular character was represented in the source using a Unicode character or an entity reference.

Entity references consist of & + any of the valid HTML5 entity names + ;. The document https://html.spec.whatwg.org/entities.json is used as an authoritative source for the valid entity references and their corresponding code points.

&nbsp; &amp; &copy; &AElig; &Dcaron;
&frac34; &HilbertSpace; &DifferentialD;
&ClockwiseContourIntegral; &ngE;
.
<p>  &amp; © Æ Ď
¾ ℋ ⅆ
∲ ≧̸</p>

Decimal numeric character references consist of &# + a string of 1–7 arabic digits + ;. A numeric character reference is parsed as the corresponding Unicode character. Invalid Unicode code points will be replaced by the REPLACEMENT CHARACTER (U+FFFD). For security reasons, the code point U+0000 will also be replaced by U+FFFD.

&#35; &#1234; &#992; &#0;
.
<p># Ӓ Ϡ �</p>

Hexadecimal numeric character references consist of &# + either X or x + a string of 1-6 hexadecimal digits + ;. They too are parsed as the corresponding Unicode character (this time specified with a hexadecimal numeral instead of decimal).

&#X22; &#XD06; &#xcab;
.
<p>&quot; ആ ಫ</p>

Here are some nonentities:

&nbsp &x; &#; &#x;
&#87654321;
&#abcdef0;
&ThisIsNotDefined; &hi?;
.
<p>&amp;nbsp &amp;x; &amp;#; &amp;#x;
&amp;#87654321;
&amp;#abcdef0;
&amp;ThisIsNotDefined; &amp;hi?;</p>

Although HTML5 does accept some entity references without a trailing semicolon (such as &copy), these are not recognized here, because it makes the grammar too ambiguous:

&copy
.
<p>&amp;copy</p>

Strings that are not on the list of HTML5 named entities are not recognized as entity references either:

&MadeUpEntity;
.
<p>&amp;MadeUpEntity;</p>

Entity and numeric character references are recognized in any context besides code spans or code blocks, including URLs, [link titles], and [fenced code block][] [info strings]:

<a href="&ouml;&ouml;.html">
.
<a href="&ouml;&ouml;.html">

[foo](/f&ouml;&ouml; "f&ouml;&ouml;")
.
<p><a href="/f%C3%B6%C3%B6" title="föö">foo</a></p>

[foo]

[foo]: /f&ouml;&ouml; "f&ouml;&ouml;"
.
<p><a href="/f%C3%B6%C3%B6" title="föö">foo</a></p>

``` f&ouml;&ouml;
foo
```
.
<pre><code class="language-föö">foo
</code></pre>

Entity and numeric character references are treated as literal text in code spans and code blocks:

`f&ouml;&ouml;`
.
<p><code>f&amp;ouml;&amp;ouml;</code></p>

    f&ouml;f&ouml;
.
<pre><code>f&amp;ouml;f&amp;ouml;
</code></pre>

Entity and numeric character references cannot be used in place of symbols indicating structure in CommonMark documents.

&#42;foo&#42;
*foo*
.
<p>*foo*
<em>foo</em></p>

&#42; foo

* foo
.
<p>* foo</p>
<ul>
<li>foo</li>
</ul>

foo&#10;&#10;bar
.
<p>foo

bar</p>

&#9;foo
.
<p>→foo</p>

[a](url &quot;tit&quot;)
.
<p>[a](url &quot;tit&quot;)</p>

Blocks and inlines

We can think of a document as a sequence of blocks—structural elements like paragraphs, block quotations, lists, headings, rules, and code blocks. Some blocks (like block quotes and list items) contain other blocks; others (like headings and paragraphs) contain inline content—text, links, emphasized text, images, code spans, and so on.

Precedence

Indicators of block structure always take precedence over indicators of inline structure. So, for example, the following is a list with two items, not a list with one item containing a code span:

- `one
- two`
.
<ul>
<li>`one</li>
<li>two`</li>
</ul>

This means that parsing can proceed in two steps: first, the block structure of the document can be discerned; second, text lines inside paragraphs, headings, and other block constructs can be parsed for inline structure. The second step requires information about link reference definitions that will be available only at the end of the first step. Note that the first step requires processing lines in sequence, but the second can be parallelized, since the inline parsing of one block element does not affect the inline parsing of any other.

Container blocks and leaf blocks

We can divide blocks into two types: container blocks, which can contain other blocks, and leaf blocks, which cannot.

Leaf blocks

This section describes the different kinds of leaf block that make up a Markdown document.

Thematic breaks

A line consisting of optionally up to three spaces of indentation, followed by a sequence of three or more matching -, _, or * characters, each followed optionally by any number of spaces or tabs, forms a thematic break.

***
---
___
.
<hr />
<hr />
<hr />

Wrong characters:

+++
.
<p>+++</p>

===
.
<p>===</p>

Not enough characters:

--
**
__
.
<p>--
**
__</p>

Up to three spaces of indentation are allowed:

 ***
  ***
   ***
.
<hr />
<hr />
<hr />

Four spaces of indentation is too many:

    ***
.
<pre><code>***
</code></pre>

Foo
    ***
.
<p>Foo
***</p>

More than three characters may be used:

_____________________________________
.
<hr />

Spaces and tabs are allowed between the characters:

 - - -
.
<hr />

 **  * ** * ** * **
.
<hr />

-     -      -      -
.
<hr />

Spaces and tabs are allowed at the end:

- - - -    
.
<hr />

However, no other characters may occur in the line:

_ _ _ _ a

a------

---a---
.
<p>_ _ _ _ a</p>
<p>a------</p>
<p>---a---</p>

It is required that all of the characters other than spaces or tabs be the same. So, this is not a thematic break:

 *-*
.
<p><em>-</em></p>

Thematic breaks do not need blank lines before or after:

- foo
***
- bar
.
<ul>
<li>foo</li>
</ul>
<hr />
<ul>
<li>bar</li>
</ul>

Thematic breaks can interrupt a paragraph:

Foo
***
bar
.
<p>Foo</p>
<hr />
<p>bar</p>

If a line of dashes that meets the above conditions for being a thematic break could also be interpreted as the underline of a [setext heading], the interpretation as a [setext heading] takes precedence. Thus, for example, this is a setext heading, not a paragraph followed by a thematic break:

Foo
---
bar
.
<h2>Foo</h2>
<p>bar</p>

When both a thematic break and a list item are possible interpretations of a line, the thematic break takes precedence:

* Foo
* * *
* Bar
.
<ul>
<li>Foo</li>
</ul>
<hr />
<ul>
<li>Bar</li>
</ul>

If you want a thematic break in a list item, use a different bullet:

- Foo
- * * *
.
<ul>
<li>Foo</li>
<li>
<hr />
</li>
</ul>

ATX headings

An ATX heading consists of a string of characters, parsed as inline content, between an opening sequence of 1–6 unescaped # characters and an optional closing sequence of any number of unescaped # characters. The opening sequence of # characters must be followed by spaces or tabs, or by the end of line. The optional closing sequence of #s must be preceded by spaces or tabs and may be followed by spaces or tabs only. The opening # character may be preceded by up to three spaces of indentation. The raw contents of the heading are stripped of leading and trailing space or tabs before being parsed as inline content. The heading level is equal to the number of # characters in the opening sequence.

Simple headings:

# foo
## foo
### foo
#### foo
##### foo
###### foo
.
<h1>foo</h1>
<h2>foo</h2>
<h3>foo</h3>
<h4>foo</h4>
<h5>foo</h5>
<h6>foo</h6>

More than six # characters is not a heading:

####### foo
.
<p>####### foo</p>

At least one space or tab is required between the # characters and the heading’s contents, unless the heading is empty. Note that many implementations currently do not require the space. However, the space was required by the original ATX implementation, and it helps prevent things like the following from being parsed as headings:

#5 bolt

#hashtag
.
<p>#5 bolt</p>
<p>#hashtag</p>

This is not a heading, because the first # is escaped:

\## foo
.
<p>## foo</p>

Contents are parsed as inlines:

# foo *bar* \*baz\*
.
<h1>foo <em>bar</em> *baz*</h1>

Leading and trailing spaces or tabs are ignored in parsing inline content:

#                  foo                     
.
<h1>foo</h1>

Up to three spaces of indentation are allowed:

 ### foo
  ## foo
   # foo
.
<h3>foo</h3>
<h2>foo</h2>
<h1>foo</h1>

Four spaces of indentation is too many:

    # foo
.
<pre><code># foo
</code></pre>

foo
    # bar
.
<p>foo
# bar</p>

A closing sequence of # characters is optional:

## foo ##
  ###   bar    ###
.
<h2>foo</h2>
<h3>bar</h3>

It need not be the same length as the opening sequence:

# foo ##################################
##### foo ##
.
<h1>foo</h1>
<h5>foo</h5>

Spaces or tabs are allowed after the closing sequence:

### foo ###     
.
<h3>foo</h3>

A sequence of # characters with anything but spaces or tabs following it is not a closing sequence, but counts as part of the contents of the heading:

### foo ### b
.
<h3>foo ### b</h3>

The closing sequence must be preceded by a space or tab:

# foo#
.
<h1>foo#</h1>

Backslash-escaped # characters do not count as part of the closing sequence:

### foo \###
## foo #\##
# foo \#
.
<h3>foo ###</h3>
<h2>foo ###</h2>
<h1>foo #</h1>

ATX headings need not be separated from surrounding content by blank lines, and they can interrupt paragraphs:

****
## foo
****
.
<hr />
<h2>foo</h2>
<hr />

Foo bar
# baz
Bar foo
.
<p>Foo bar</p>
<h1>baz</h1>
<p>Bar foo</p>

ATX headings can be empty:

## 
#
### ###
.
<h2></h2>
<h1></h1>
<h3></h3>

Setext headings

A setext heading consists of one or more lines of text, not interrupted by a blank line, of which the first line does not have more than 3 spaces of indentation, followed by a [setext heading underline]. The lines of text must be such that, were they not followed by the setext heading underline, they would be interpreted as a paragraph: they cannot be interpretable as a [code fence], [ATX heading][ATX headings], [block quote][block quotes], [thematic break][thematic breaks], [list item][list items], or [HTML block][HTML blocks].

A setext heading underline is a sequence of = characters or a sequence of - characters, with no more than 3 spaces of indentation and any number of trailing spaces or tabs.

The heading is a level 1 heading if = characters are used in the [setext heading underline], and a level 2 heading if - characters are used. The contents of the heading are the result of parsing the preceding lines of text as CommonMark inline content.

In general, a setext heading need not be preceded or followed by a blank line. However, it cannot interrupt a paragraph, so when a setext heading comes after a paragraph, a blank line is needed between them.

Simple examples:

Foo *bar*
=========

Foo *bar*
---------
.
<h1>Foo <em>bar</em></h1>
<h2>Foo <em>bar</em></h2>

The content of the header may span more than one line:

Foo *bar
baz*
====
.
<h1>Foo <em>bar
baz</em></h1>

The contents are the result of parsing the headings’s raw content as inlines. The heading’s raw content is formed by concatenating the lines and removing initial and final spaces or tabs.

  Foo *bar
baz*→
====
.
<h1>Foo <em>bar
baz</em></h1>

The underlining can be any length:

Foo
-------------------------

Foo
=
.
<h2>Foo</h2>
<h1>Foo</h1>

The heading content can be preceded by up to three spaces of indentation, and need not line up with the underlining:

   Foo
---

  Foo
-----

  Foo
  ===
.
<h2>Foo</h2>
<h2>Foo</h2>
<h1>Foo</h1>

Four spaces of indentation is too many:

    Foo
    ---

    Foo
---
.
<pre><code>Foo
---

Foo
</code></pre>
<hr />

The setext heading underline can be preceded by up to three spaces of indentation, and may have trailing spaces or tabs:

Foo
   ----      
.
<h2>Foo</h2>

Four spaces of indentation is too many:

Foo
    ---
.
<p>Foo
---</p>

The setext heading underline cannot contain internal spaces or tabs:

Foo
= =

Foo
--- -
.
<p>Foo
= =</p>
<p>Foo</p>
<hr />

Trailing spaces or tabs in the content line do not cause a hard line break:

Foo  
-----
.
<h2>Foo</h2>

Nor does a backslash at the end:

Foo\
----
.
<h2>Foo\</h2>

Since indicators of block structure take precedence over indicators of inline structure, the following are setext headings:

`Foo
----
`

<a title="a lot
---
of dashes"/>
.
<h2>`Foo</h2>
<p>`</p>
<h2>&lt;a title=&quot;a lot</h2>
<p>of dashes&quot;/&gt;</p>

The setext heading underline cannot be a [lazy continuation line] in a list item or block quote:

> Foo
---
.
<blockquote>
<p>Foo</p>
</blockquote>
<hr />

> foo
bar
===
.
<blockquote>
<p>foo
bar
===</p>
</blockquote>

- Foo
---
.
<ul>
<li>Foo</li>
</ul>
<hr />

A blank line is needed between a paragraph and a following setext heading, since otherwise the paragraph becomes part of the heading’s content:

Foo
Bar
---
.
<h2>Foo
Bar</h2>

But in general a blank line is not required before or after setext headings:

---
Foo
---
Bar
---
Baz
.
<hr />
<h2>Foo</h2>
<h2>Bar</h2>
<p>Baz</p>

Setext headings cannot be empty:


====
.
<p>====</p>

Setext heading text lines must not be interpretable as block constructs other than paragraphs. So, the line of dashes in these examples gets interpreted as a thematic break:

---
---
.
<hr />
<hr />

- foo
-----
.
<ul>
<li>foo</li>
</ul>
<hr />

    foo
---
.
<pre><code>foo
</code></pre>
<hr />

> foo
-----
.
<blockquote>
<p>foo</p>
</blockquote>
<hr />

If you want a heading with > foo as its literal text, you can use backslash escapes:

\> foo
------
.
<h2>&gt; foo</h2>

Compatibility note: Most existing Markdown implementations do not allow the text of setext headings to span multiple lines. But there is no consensus about how to interpret

Foo
bar
---
baz

One can find four different interpretations:

  1. paragraph “Foo”, heading “bar”, paragraph “baz”
  2. paragraph “Foo bar”, thematic break, paragraph “baz”
  3. paragraph “Foo bar — baz”
  4. heading “Foo bar”, paragraph “baz”

We find interpretation 4 most natural, and interpretation 4 increases the expressive power of CommonMark, by allowing multiline headings. Authors who want interpretation 1 can put a blank line after the first paragraph:

Foo

bar
---
baz
.
<p>Foo</p>
<h2>bar</h2>
<p>baz</p>

Authors who want interpretation 2 can put blank lines around the thematic break,

Foo
bar

---

baz
.
<p>Foo
bar</p>
<hr />
<p>baz</p>

or use a thematic break that cannot count as a [setext heading underline], such as

Foo
bar
* * *
baz
.
<p>Foo
bar</p>
<hr />
<p>baz</p>

Authors who want interpretation 3 can use backslash escapes:

Foo
bar
\---
baz
.
<p>Foo
bar
---
baz</p>

Indented code blocks

An indented code block is composed of one or more [indented chunks] separated by blank lines. An indented chunk is a sequence of non-blank lines, each preceded by four or more spaces of indentation. The contents of the code block are the literal contents of the lines, including trailing [line endings], minus four spaces of indentation. An indented code block has no [info string].

An indented code block cannot interrupt a paragraph, so there must be a blank line between a paragraph and a following indented code block. (A blank line is not needed, however, between a code block and a following paragraph.)

    a simple
      indented code block
.
<pre><code>a simple
  indented code block
</code></pre>

If there is any ambiguity between an interpretation of indentation as a code block and as indicating that material belongs to a [list item][list items], the list item interpretation takes precedence:

  - foo

    bar
.
<ul>
<li>
<p>foo</p>
<p>bar</p>
</li>
</ul>

1.  foo

    - bar
.
<ol>
<li>
<p>foo</p>
<ul>
<li>bar</li>
</ul>
</li>
</ol>

The contents of a code block are literal text, and do not get parsed as Markdown:

    <a/>
    *hi*

    - one
.
<pre><code>&lt;a/&gt;
*hi*

- one
</code></pre>

Here we have three chunks separated by blank lines:

    chunk1

    chunk2
  
 
 
    chunk3
.
<pre><code>chunk1

chunk2



chunk3
</code></pre>

Any initial spaces or tabs beyond four spaces of indentation will be included in the content, even in interior blank lines:

    chunk1
      
      chunk2
.
<pre><code>chunk1
  
  chunk2
</code></pre>

An indented code block cannot interrupt a paragraph. (This allows hanging indents and the like.)

Foo
    bar

.
<p>Foo
bar</p>

However, any non-blank line with fewer than four spaces of indentation ends the code block immediately. So a paragraph may occur immediately after indented code:

    foo
bar
.
<pre><code>foo
</code></pre>
<p>bar</p>

And indented code can occur immediately before and after other kinds of blocks:

# Heading
    foo
Heading
------
    foo
----
.
<h1>Heading</h1>
<pre><code>foo
</code></pre>
<h2>Heading</h2>
<pre><code>foo
</code></pre>
<hr />

The first line can be preceded by more than four spaces of indentation:

        foo
    bar
.
<pre><code>    foo
bar
</code></pre>

Blank lines preceding or following an indented code block are not included in it:


    
    foo
    

.
<pre><code>foo
</code></pre>

Trailing spaces or tabs are included in the code block’s content:

    foo  
.
<pre><code>foo  
</code></pre>

Fenced code blocks

A code fence is a sequence of at least three consecutive backtick characters (`) or tildes (~). (Tildes and backticks cannot be mixed.) A fenced code block begins with a code fence, preceded by up to three spaces of indentation.

The line with the opening code fence may optionally contain some text following the code fence; this is trimmed of leading and trailing spaces or tabs and called the info string. If the [info string] comes after a backtick fence, it must not contain any backtick characters. (The reason for this restriction is that otherwise some inline code would be incorrectly interpreted as the beginning of a fenced code block.)

The content of the code block consists of all subsequent lines, until a closing [code fence] of the same type as the code block began with (backticks or tildes), and with at least as many backticks or tildes as the opening code fence. If the leading code fence is preceded by N spaces of indentation, then up to N spaces of indentation are removed from each line of the content (if present). (If a content line is not indented, it is preserved unchanged. If it is indented N spaces or less, all of the indentation is removed.)

The closing code fence may be preceded by up to three spaces of indentation, and may be followed only by spaces or tabs, which are ignored. If the end of the containing block (or document) is reached and no closing code fence has been found, the code block contains all of the lines after the opening code fence until the end of the containing block (or document). (An alternative spec would require backtracking in the event that a closing code fence is not found. But this makes parsing much less efficient, and there seems to be no real downside to the behavior described here.)

A fenced code block may interrupt a paragraph, and does not require a blank line either before or after.

The content of a code fence is treated as literal text, not parsed as inlines. The first word of the [info string] is typically used to specify the language of the code sample, and rendered in the class attribute of the code tag. However, this spec does not mandate any particular treatment of the [info string].

Here is a simple example with backticks:

```
<
 >
```
.
<pre><code>&lt;
 &gt;
</code></pre>

With tildes:

~~~
<
 >
~~~
.
<pre><code>&lt;
 &gt;
</code></pre>

Fewer than three backticks is not enough:

``
foo
``
.
<p><code>foo</code></p>

The closing code fence must use the same character as the opening fence:

```
aaa
~~~
```
.
<pre><code>aaa
~~~
</code></pre>

~~~
aaa
```
~~~
.
<pre><code>aaa
```
</code></pre>

The closing code fence must be at least as long as the opening fence:

````
aaa
```
``````
.
<pre><code>aaa
```
</code></pre>

~~~~
aaa
~~~
~~~~
.
<pre><code>aaa
~~~
</code></pre>

Unclosed code blocks are closed by the end of the document (or the enclosing [block quote][block quotes] or [list item][list items]):

```
.
<pre><code></code></pre>

`````

```
aaa
.
<pre><code>
```
aaa
</code></pre>

> ```
> aaa

bbb
.
<blockquote>
<pre><code>aaa
</code></pre>
</blockquote>
<p>bbb</p>

A code block can have all empty lines as its content:

```

  
```
.
<pre><code>
  
</code></pre>

A code block can be empty:

```
```
.
<pre><code></code></pre>

Fences can be indented. If the opening fence is indented, content lines will have equivalent opening indentation removed, if present:

 ```
 aaa
aaa
```
.
<pre><code>aaa
aaa
</code></pre>

  ```
aaa
  aaa
aaa
  ```
.
<pre><code>aaa
aaa
aaa
</code></pre>

   ```
   aaa
    aaa
  aaa
   ```
.
<pre><code>aaa
 aaa
aaa
</code></pre>

Four spaces of indentation is too many:

    ```
    aaa
    ```
.
<pre><code>```
aaa
```
</code></pre>

Closing fences may be preceded by up to three spaces of indentation, and their indentation need not match that of the opening fence:

```
aaa
  ```
.
<pre><code>aaa
</code></pre>

   ```
aaa
  ```
.
<pre><code>aaa
</code></pre>

This is not a closing fence, because it is indented 4 spaces:

```
aaa
    ```
.
<pre><code>aaa
    ```
</code></pre>

Code fences (opening and closing) cannot contain internal spaces or tabs:

``` ```
aaa
.
<p><code> </code>
aaa</p>

~~~~~~
aaa
~~~ ~~
.
<pre><code>aaa
~~~ ~~
</code></pre>

Fenced code blocks can interrupt paragraphs, and can be followed directly by paragraphs, without a blank line between:

foo
```
bar
```
baz
.
<p>foo</p>
<pre><code>bar
</code></pre>
<p>baz</p>

Other blocks can also occur before and after fenced code blocks without an intervening blank line:

foo
---
~~~
bar
~~~
# baz
.
<h2>foo</h2>
<pre><code>bar
</code></pre>
<h1>baz</h1>

An [info string] can be provided after the opening code fence. Although this spec doesn’t mandate any particular treatment of the info string, the first word is typically used to specify the language of the code block. In HTML output, the language is normally indicated by adding a class to the code element consisting of language- followed by the language name.

```ruby
def foo(x)
  return 3
end
```
.
<pre><code class="language-ruby">def foo(x)
  return 3
end
</code></pre>

~~~~    ruby startline=3 $%@#$
def foo(x)
  return 3
end
~~~~~~~
.
<pre><code class="language-ruby">def foo(x)
  return 3
end
</code></pre>

````;
````
.
<pre><code class="language-;"></code></pre>

[Info strings] for backtick code blocks cannot contain backticks:

``` aa ```
foo
.
<p><code>aa</code>
foo</p>

[Info strings] for tilde code blocks can contain backticks and tildes:

~~~ aa ``` ~~~
foo
~~~
.
<pre><code class="language-aa">foo
</code></pre>

Closing code fences cannot have [info strings]:

```
``` aaa
```
.
<pre><code>``` aaa
</code></pre>

HTML blocks

An HTML block is a group of lines that is treated as raw HTML (and will not be escaped in HTML output).

There are seven kinds of [HTML block], which can be defined by their start and end conditions. The block begins with a line that meets a start condition (after up to three optional spaces of indentation). It ends with the first subsequent line that meets a matching end condition, or the last line of the document, or the last line of the container block containing the current HTML block, if no line is encountered that meets the [end condition]. If the first line meets both the [start condition] and the [end condition], the block will contain just that line.

  1. Start condition: line begins with the string <pre, <script, <style, or <textarea (case-insensitive), followed by a space, a tab, the string >, or the end of the line.
    End condition: line contains an end tag </pre>, </script>, </style>, or </textarea> (case-insensitive; it need