Edit Help

Markdown is a lightweight markup language with plain text formatting syntax and is widely used for blogging and documentation pages. On this platform, we have particular implements for math contents like automatic numbering and referencing, latex packages inclusion, custom commands, and theorem-like blocks. The following is an introduction to the markdown syntax, primarily excerpt from the pandoc document. You may copy syntax examples to the editor demo below and play with them.

Inline formatting

Emphasis

To emphasize some text, surround it with *s or _, like this:

This text is _emphasized with underscores_, and this
is *emphasized with asterisks*.

Double * or _ produces strong emphasis:

This is **strong emphasis** and __with underscores__.

A * or _ character surrounded by spaces, or backslash-escaped, will not trigger emphasis:

This is * not emphasized *, and \*neither is this\*.

Because _ is sometimes used inside words and identifiers, pandoc does not interpret a _ surrounded by alphanumeric characters as an emphasis marker. If you want to emphasize just part of a word, use *:

feas*ible*, not feas*able*.

Strikeout

To strike out a section of text with a horizontal line, begin and end it with ~~. Thus, for example,

This ~~is deleted text.~~

Superscripts and subscripts

Superscripts may be written by surrounding the superscripted text by ^ characters; subscripts may be written by surrounding the subscripted text by ~ characters. Thus, for example,

H~2~O is a liquid.  2^10^ is 1024.

The text between ^...^ or ~...~ may not contain spaces or newlines. If the superscripted or subscripted text contains spaces, these spaces must be escaped with backslashes. (This is to prevent accidental superscripting and subscripting through the ordinary use of ~ and ^, and also bad interactions with footnotes.) Thus, if you want the letter P with ‘a cat’ in subscripts, use P~a\ cat~, not P~a cat~.

Verbatim

To make a short span of text verbatim, put it inside backticks:

What is the difference between `>>=` and `>>`?

If the verbatim text includes a backtick, use double backticks:

Here is a literal backtick `` ` ``.

(The spaces after the opening backticks and before the closing backticks will be ignored.)

The general rule is that a verbatim span starts with a string of consecutive backticks and ends with a string of the same number of backticks.

Backslash escapes

Except inside a code block or inline code, any punctuation or space character preceded by a backslash will be treated literally, even if it would normally indicate formatting.

Links

Markdown allows links to be specified in several ways.

Automatic links

If you enclose a URL or email address in pointy brackets, it will become a link:

<https://google.com>
<[email protected]>

Inline links

An inline link consists of the link text in square brackets, followed by the URL in parentheses. (Optionally, the URL can be followed by a link title, in quotes.)

This is an [inline link](/url), and here's [one with
a title](https://fsf.org "click here for a good time!").

Email addresses in inline links are not autodetected, so they have to be prefixed with mailto:

[Write me!](mailto:[email protected])

Reference links

An explicit reference link has two parts, the link itself and the link definition, which may occur elsewhere in the document (either before or after the link).

The link consists of link text in square brackets, followed by a label in square brackets. (There cannot be space between the two unless the spaced_reference_links extension is enabled.) The link definition consists of the bracketed label, followed by a colon and a space, followed by the URL, and optionally (after a space) a link title either in quotes or in parentheses. The label must not be parseable as a citation: citations take precedence over link labels.

Here are some examples:

[my label 1]: /foo/bar.html  "My title, optional"
[my label 2]: /foo
[my label 3]: https://fsf.org (The Free Software Foundation)
[my label 4]: /bar#special  'A title in single quotes'
[my label 5]: <http://foo.bar.baz>

Note that link labels are not case sensitive. So, this will work:

Here is [my link][FOO]

[Foo]: /bar/baz

In an implicit reference link, the second pair of brackets is empty:

See [my website][].

[my website]: http://foo.bar.baz

In a shortcut reference link, the second pair of brackets may be omitted entirely:

See [my website].

[my website]: http://foo.bar.baz

Internal links

To link to another section of the same document, use the automatically generated identifier (see Heading identifiers). For example:

See the [Introduction](#introduction).
or

See the [Introduction].

[Introduction]: #introduction

Images

A link immediately preceded by a ! will be treated as an image. The link text will be used as the image’s alt text:

![la lune](lalune.jpg "Voyage to the moon")

![movie reel]

[movie reel]: movie.gif

An image with nonempty alt text, occurring by itself in a paragraph, will be rendered as a figure with a caption. The image’s alt text will be used as the caption.

![This is the caption](/url/of/image.png)

If you just want a regular inline image, just make sure it is not the only thing in the paragraph. One way to do this is to insert a nonbreaking space after the image:

![This image won't be a figure](/url/of/image.png)\

Attributes can be set on links and images:

An inline ![image](foo.jpg){#id width=30 height=20px}
and a reference ![image][ref] with attributes.

[ref]: foo.jpg "optional title" {#id .class key=val key2="val 2"}
(This syntax is compatible with PHP Markdown Extra when only #id and .class are used.)

The width and height attributes on images are treated specially. When used without a unit, the unit is assumed to be pixels. However, any of the following unit identifiers can be used: pt, cm, in, inch and %. There must not be any spaces between the number and the unit. For example:

![](file.jpg){ width=50% }

Footnotes

Footnotes are allowed, using the following syntax:

Here is a footnote reference,[^1] and another.[^longnote]

[^1]: Here is the footnote.

[^longnote]: Here's one with multiple blocks.

    Subsequent paragraphs are indented to show that they
belong to the previous footnote.

        { some.code }

    The whole paragraph can be indented, or just the first
    line.  In this way, multi-paragraph footnotes work like
    multi-paragraph list items.

This paragraph won't be part of the note, because it
isn't indented.

The identifiers in footnote references may not contain spaces, tabs, or newlines. These identifiers are used only to correlate the footnote reference with the note itself; in the output, footnotes will be numbered sequentially.

The footnotes themselves need not be placed at the end of the document. They may appear anywhere except inside other block elements (lists, block quotes, tables, etc.). Each footnote should be separated from surrounding content (including other footnotes) by blank lines.

Inline footnotes are also allowed (though, unlike regular notes, they cannot contain multiple paragraphs). The syntax is as follows:

Here is an inline note.^[Inline notes are easier to write, since
you don't have to pick an identifier and move down to type the
note.]

Inline and regular footnotes may be mixed freely.

Citation

To cite a bibliographic item with an identifier foo, use the syntax @foo. Normal citations should be included in square brackets, with semicolons separating distinct items:

Blah blah [@doe99; @smith2000; @smith2004].

Unless a citation key starts with a letter, digit, or _, and contains only alphanumerics and single internal punctuation characters (:.#$%&-+?<>~/), it must be surrounded by curly braces, which are not considered part of the key. In @Foo_bar.baz., the key is Foo_bar.baz because the final period is not internal punctuation, so it is not included in the key. In @{Foo_bar.baz.}, the key is Foo_bar.baz., including the final period. In @Foo_bar--baz, the key is Foo_bar because the repeated internal punctuation characters terminate the key. The curly braces are recommended if you use URLs as keys: [@{https://example.com/bib?name=foobar&date=2000}, p. 33].

Citation items may optionally include a prefix, a locator, and a suffix. In

Blah blah [see @doe99, pp. 33-35 and *passim*; @smith04, chap. 1].

the first item (doe99) has prefix see, locator pp. 33-35, and suffix and *passim*. The second item (smith04) has locator chap. 1 and no prefix or suffix.

In complex cases, you can force something to be treated as a locator by enclosing it in curly braces or prevent parsing the suffix as locator by prepending curly braces:

[@smith{ii, A, D-Z}, with a suffix]
[@smith, {pp. iv, vi-xi, (xv)-(xvii)} with suffix here]
[@smith{}, 99 years later]
A minus sign (-) before the @ will suppress mention of the author in the citation. This can be useful when the author is already mentioned in the text:

Smith says blah [-@smith04].
You can also write an author-in-text citation, by omitting the square brackets:

@smith04 says blah.

@smith04 [p. 33] says blah.

This will cause the author’s name to be rendered, followed by the bibliographical details. Use this form when you want to make the citation the subject of a sentence.

Paragraphs

A paragraph is one or more lines of text followed by one or more blank lines. Newlines are treated as spaces, so you can reflow your paragraphs as you like.

If you need a hard line break, put two or more spaces at the end of a line. A backslash followed by a newline is also a hard line break.

Headings

A heading consists of one to six # signs and a line of text, optionally followed by any number of # signs. The number of # signs at the beginning of the line is the heading level:

## A level-two heading

### A level-three heading ###

Block quotations

Markdown uses email conventions for quoting blocks of text. A block quotation is one or more paragraphs or other block elements (such as lists or headings), with each line preceded by a > character.

> This is a block quote. This
> paragraph has two lines.
>
> 1. This is a list inside a block quote.
> 2. Second item.

A “lazy” form, which requires the > character only on the first line of each block, is also allowed:

> This is a block quote. This
paragraph has two lines.

> 1. This is a list inside a block quote.
2. Second item.

Among the block elements that can be contained in a block quote are other block quotes. That is, block quotes can be nested:

> This is a block quote.
>
> > A block quote within a block quote.

Code blocks

A block of text indented four spaces (or one tab) is treated as verbatim text: that is, special characters do not trigger special formatting, and all spaces and line breaks are preserved. For example,

    if (a > 3) {
      moveShip(5 * gravity, DOWN);
    }

In addition to standard indented code blocks, fenced code blocks are also supported. These begin with a row of three or more tildes (~) and end with a row of tildes that must be at least as long as the starting row. Everything between these lines is treated as code. No indentation is necessary:

~~~
if (a > 3) {
  moveShip(5 * gravity, DOWN);
}
~~~~~~~

Lists

A bulleted list item begins with a bullet (*, +, or -). Here is a simple example:

* one
* two
* three

This will produce a “compact” list. If you want a “loose” list, in which each item is formatted as a paragraph, put spaces between the items:

* one

* two

* three

List items may include other lists. In this case the preceding blank line is optional. The nested list must be indented to line up with the first non-space character after the list marker of the containing list item.

* fruits
  + apples
    - macintosh
    - red delicious
  + pears
  + peaches
* vegetables
  + broccoli
  + chard

Ordered lists work just like bulleted lists, except that the items begin with enumerators or # rather than bullets.

1.  one
8.  two
7.  three

and this one:

#. one
#. two

Task lists are supported too:

- [ ] an unchecked task list item
- [x] checked item

The special list marker @ can be used for sequentially numbered examples. The first list item with a @ marker will be numbered ‘1’, the next ‘2’, and so on, throughout the document. The numbered examples need not occur in a single list; each new list using @ will take up where the last stopped. So, for example:

(@)  My first example will be numbered (1).
(@)  My second example will be numbered (2).

Explanation of examples.

(@)  My third example will be numbered (3).

Numbered examples can be labeled and referred to elsewhere in the document:

(@good)  This is a good example.

As (@good) illustrates, ...

The label can be any string of alphanumeric characters, underscores, or hyphens.

Horizontal rules

A line containing a row of three or more *, -, or _ characters (optionally separated by spaces) produces a horizontal rule:

*  *  *  *

---------------

Note that horizontal rules should be separated from surrounding text by blank lines.

Tables

Simple tables look like this:

  Right     Left     Center     Default
-------     ------ ----------   -------
     12     12        12            12
    123     123       123          123
      1     1          1             1

Table:  Demonstration of simple table syntax.

The header and table rows must each fit on one line. Column alignments are determined by the position of the header text relative to the dashed line below it:3

If the dashed line is flush with the header text on the right side but extends beyond it on the left, the column is right-aligned.
If the dashed line is flush with the header text on the left side but extends beyond it on the right, the column is left-aligned.
If the dashed line extends beyond the header text on both sides, the column is centered.
If the dashed line is flush with the header text on both sides, the default alignment is used (in most cases, this will be left). -The table must end with a blank line, or a line of dashes followed by a blank line.

The column header row may be omitted, provided a dashed line is used to end the table. For example:

-------     ------ ----------   -------
     12     12        12             12
    123     123       123           123
      1     1          1              1
-------     ------ ----------   -------

When the header row is omitted, column alignments are determined on the basis of the first line of the table body. So, in the tables above, the columns would be right, left, center, and right aligned, respectively.

Multiline tables allow header and table rows to span multiple lines of text (but cells that span multiple columns or rows of the table are not supported). Here is an example:

-------------------------------------------------------------
 Centered   Default           Right Left
  Header    Aligned         Aligned Aligned
----------- ------- --------------- -------------------------
   First    row                12.0 Example of a row that
                                    spans multiple lines.

  Second    row                 5.0 Here's another one. Note
                                    the blank line between
                                    rows.
-------------------------------------------------------------

Table: Here's the caption. It, too, may span
multiple lines.

These work like simple tables, but with the following differences:

They must begin with a row of dashes, before the header text (unless the header row is omitted). They must end with a row of dashes, then a blank line. The rows must be separated by blank lines. In multiline tables, the table parser pays attention to the widths of the columns, and the writers try to reproduce these relative widths in the output. So, if you find that one of the columns is too narrow in the output, try widening it in the Markdown source. The header may be omitted in multiline tables as well as simple tables. It is possible for a multiline table to have just one row, but the row should be followed by a blank line (and then the row of dashes that ends the table), or the table may be interpreted as a simple table.

Grid tables look like this:

: Sample grid table.

+---------------+---------------+--------------------+
| Fruit         | Price         | Advantages         |
+===============+===============+====================+
| Bananas       | $1.34         | - built-in wrapper |
|               |               | - bright color     |
+---------------+---------------+--------------------+
| Oranges       | $2.10         | - cures scurvy     |
|               |               | - tasty            |
+---------------+---------------+--------------------+

The row of =s separates the header from the table body, and can be omitted for a headerless table. The cells of grid tables may contain arbitrary block elements (multiple paragraphs, code blocks, lists, etc.).

Cells can span multiple columns or rows:

+---------------------+----------+
| Property            | Earth    |
+=============+=======+==========+
|             | min   | -89.2 °C |
| Temperature +-------+----------+
| 1961-1990   | mean  | 14 °C    |
|             +-------+----------+
|             | max   | 56.7 °C  |
+-------------+-------+----------+

A table header may contain more than one row:

+---------------------+-----------------------+
| Location            | Temperature 1961-1990 |
|                     | in degree Celsius     |
|                     +-------+-------+-------+
|                     | min   | mean  | max   |
+=====================+=======+=======+=======+
| Antarctica          | -89.2 | N/A   | 19.8  |
+---------------------+-------+-------+-------+
| Earth               | -89.2 | 14    | 56.7  |
+---------------------+-------+-------+-------+

Alignments can be specified as with pipe tables, by putting colons at the boundaries of the separator line after the header:

+---------------+---------------+--------------------+
| Right         | Left          | Centered           |
+==============:+:==============+:==================:+
| Bananas       | $1.34         | built-in wrapper   |
+---------------+---------------+--------------------+

For headerless tables, the colons go on the top line instead:

+--------------:+:--------------+:------------------:+
| Right         | Left          | Centered           |
+---------------+---------------+--------------------+

A table foot can be defined by enclosing it with separator lines that use = instead of -:

 +---------------+---------------+
 | Fruit         | Price         |
 +===============+===============+
 | Bananas       | $1.34         |
 +---------------+---------------+
 | Oranges       | $2.10         |
 +===============+===============+
 | Sum           | $3.44         |
 +===============+===============+

The foot must always be placed at the very bottom of the table.

Pipe tables look like this:

| Right | Left | Default | Center |
|------:|:-----|---------|:------:|
|   12  |  12  |    12   |    12  |
|  123  |  123 |   123   |   123  |
|    1  |    1 |     1   |     1  |

  : Demonstration of pipe table syntax.

The beginning and ending pipe characters are optional, but pipes are required between all columns. The colons indicate column alignment as shown. The header cannot be omitted. To simulate a headerless table, include a header with blank cells.

Since the pipes indicate column boundaries, columns need not be vertically aligned, as they are in the above example. So, this is a perfectly legal (though ugly) pipe table:

fruit| price
-----|-----:
apple|2.05
pear|1.37
orange|3.09

The cells of pipe tables cannot contain block elements like paragraphs and lists, and cannot span multiple lines. If any line of the markdown source is longer than the column width, then the table will take up the full text width and the cell contents will wrap, with the relative cell widths determined by the number of dashes in the line separating the table header from the table body. (For example ---|- would make the first column 3/4 and the second column 1/4 of the full text width.) On the other hand, if no lines are wider than column width, then cell contents will not be wrapped, and the cells will be sized to their contents.

General blocks and inlines

A bracketed sequence of inlines will be treated as an inline with attributes if it is followed immediately by attributes:

[This is *some text*]{.underline}

The underline prefixed with a dot are the style attributes of the inline, which will underline the text. We also offer mark style attributes for highlighting the text.

A general block starts with a fence containing at least three consecutive colons plus some attributes, and ends with another line containing a string of at least three consecutive colons. The block should be separated by blank lines from preceding and following blocks. Example:

::::: {#special .mark}
Here is a paragraph.

And another.
:::::

We also support a special style attribute theorem-like for theorem-like blocks:

::::: {.theorem-like #theorem-id name="Thm" title="Fermat's Last Theorem"}
No three positive integers $a$, $b$, and $c$ satisfy the equation $a^n + b^n = c^n$ for any integer value of $n$ greater than $2$.
:::::

The above will be rendered as:

Thm 1Fermat's Last TheoremNo three positive integers , , and satisfy the equation for any integer value of greater than .

Theorems are automatically numbered, if you don’t want numbering, add .unnumbered to the attributes. Theorem-like blocks can be automatically linked to using the following syntax:

[](#theorem-id)

Another special style attribute is proof-like, which is used for proofs:

::::: {.proof-like name="Fermat's lost proof"}
I have a proof of this theorem, but there is not enough space.
:::::

The proof-like block will not be numbered and a box will be added to the end of the block. There is nothing else different from a theorem-like block.

Math

Anything between two $ characters will be treated as TeX math, for example,

$\Gamma(n) = (n-1)!\quad\forall n\in\mathbb N$

The opening $ must have a non-space character immediately to its right, while the closing $ must have a non-space character immediately to its left, and must not be followed immediately by a digit. Thus, $20,000 and $30,000 won’t parse as math. If for some reason you need to enclose text in literal $ characters, backslash-escape them and they won’t be treated as math delimiters.

For display math, use $$ delimiters. (In this case, the delimiters may be separated from the formula by whitespace. However, there can be no blank lines between the opening and closing $$ delimiters.)

Note that in LaTeX environments, like

\begin{tabular}{|l|l|}\hline
Age & Frequency \\ \hline
18--25  & 15 \\
26--35  & 33 \\
36--45  & 22 \\ \hline
\end{tabular}

the material between the begin and end tags will be interpreted as raw LaTeX, not as Markdown.

Inline TeX commands will be preserved and passed unchanged. Thus, for example, you can use LaTeX to reference a formula:

\begin{equation}
  \label{eq:emc}
  e = mc^2
\end{equation}
The equation \eqref{eq:emc} is known as Einstein's mass-energy equivalence.

Markdown Help