Original Markdown is the dialect defined by John Gruber and Aaron Swartz in 2004 — the starting point from which every other Markdown flavour grew. It introduced the syntax most people recognise today: headings with #, emphasis with *, links in square brackets, and code in backticks. Nearly every Markdown tool in existence traces its syntax directly back to this specification.

Original Markdown is listed throughout this book's flavour support tables as a historical reference point. It is not a dialect you would choose for a new project today — for the reasons explained below — but understanding it clarifies why modern flavours exist and what they were designed to fix.

Best Practice

Do not write 'to the original Markdown spec' as a deliberate choice — the specification was never updated after 2004 and leaves too many parsing edge cases undefined.
Use CommonMark instead: it covers the same core elements with precise, unambiguous rules and near-universal renderer support.
Original Markdown syntax is perfectly valid CommonMark for all the elements it defines — choosing CommonMark does not mean rewriting anything. It means choosing a spec that clearly defines what happens in every case.

Notes

Origin

John Gruber published the first version of Markdown in March 2004, with significant contribution from Aaron Swartz. Swartz wrote the initial Perl implementation — a script called Markdown.pl — that converted Markdown-formatted text to HTML. Gruber developed the specification and published it alongside the script on his website, Daring Fireball.

The name 'Markdown' was a deliberate play on 'markup' — the idea being that you mark down rather than mark up, writing plain text that is readable as-is and also convertible to HTML.

Note

'Markup' comes from traditional publishing, where editors annotated manuscripts with handwritten instructions for the typesetter — underline this, make this a heading, indent this paragraph. In computing, a markup language embeds those instructions in the text itself, surrounding words with tags that describe how they should be displayed. HTML is the most familiar example: <strong>important</strong> tells the browser to display the word in bold. Markdown takes the opposite approach — instead of adding tags around your text, you write in the plain-text conventions people already used naturally in emails and letters, and the tool converts them to HTML for you.

Swartz was 17 at the time. He went on to co-create RSS 1.0, contribute to the development of Creative Commons licences, and co-found Reddit, before his death in 2013. His contribution to Markdown is often underacknowledged.

The Specification Problem

Gruber's specification was deliberately informal. It described the most common syntax cases through examples, but it did not define what a parser should do when syntax elements overlapped or conflicted. Questions like 'does this asterisk open emphasis or is it a list marker?' or 'how many spaces indent a code block inside a list?' were left to each implementer to decide.

This was a reasonable approach for a personal publishing tool in 2004. It became a significant problem as Markdown spread. By the early 2010s, dozens of Markdown parsers existed — and they all handled edge cases differently. A document that rendered correctly in one tool would produce garbled output in another. Writers who shared Markdown files across tools had no guarantee of consistent results.

Gruber did not update the specification after its initial release. He has stated that the ambiguity was partly intentional — he did not want to over-specify a format designed to be simple — but the ecosystem had outgrown the original design.

This divergence was the direct motivation for the CommonMark project, launched in 2012 and published in 2014.

What the Specification Defines

Despite its informality, the original specification defined almost all of the core Markdown elements still in use today:

Headings in ATX style (# prefix) and setext style (underline)
Paragraphs separated by blank lines
Blockquotes with > prefix
Unordered lists with -, *, or +
Ordered lists with numbers and a period
Code spans in backticks and indented code blocks
Horizontal rules with ---, ***, or ___
Links in inline and reference-style forms
Images using ! before a link
Emphasis with * or _, and strong emphasis with ** or __
Automatic escaping of HTML entities in output
Inline HTML passthrough

The specification also included a Markdown-to-HTML conversion reference table and a set of worked examples — but these were illustrative, not exhaustive.

Why No Tool Implements It Exactly

No modern Markdown tool implements strictly and only the original specification, for two reasons.

First, the specification does not cover enough cases to write a complete parser from it alone. Any serious implementation must make decisions about edge cases that the specification leaves silent. Different tools made different decisions, producing incompatible variants.

Second, the original Markdown.pl script contained behaviours that were never formally documented — behaviours that some tools reproduced faithfully and others ignored. The script was effectively a second, implicit specification that did not always agree with the written one.

CommonMark resolved this by treating the original specification and the Markdown.pl behaviour as evidence rather than authority, and writing a new, complete specification from scratch. Tools that implement CommonMark agree on every parsing case, including those the original specification never addressed.

Practical Examples

The elements below were all defined in the original 2004 specification. They are inherited by every Markdown flavour and render consistently across all compliant tools — they are the stable core of the language.

A simple travel diary entry: Headings, paragraphs, emphasis, and links were all part of the original spec. A page written with only these elements works in every Markdown renderer, from the simplest to the most advanced.

Syntax

MARKDOWN

# Kyoto, Day Three

We spent the morning at the Fushimi Inari shrine — the famous path of *thousands* of
vermilion torii gates winding up the hillside. Arriving before eight o'clock meant we
had the lower trail almost to ourselves.

## The Climb

The full route to the summit takes about two hours. We turned back at the halfway point,
which gave us time for lunch in the old town before the afternoon rain arrived.

For a useful guide to the route, see [the shrine's own website](https://inari.jp/en/).

Output

Kyoto, Day Three

We spent the morning at the Fushimi Inari shrine — the famous path of thousands of vermilion torii gates winding up the hillside. Arriving before eight o'clock meant we had the lower trail almost to ourselves.

The Climb

The full route to the summit takes about two hours. We turned back at the halfway point, which gave us time for lunch in the old town before the afternoon rain arrived.

For a useful guide to the route, see the shrine's own website.

A reading list using reference-style links: Reference-style links were also part of the original specification — useful when several books link to the same retailer or review site and you want to keep the prose clean.

Syntax

MARKDOWN

## Currently Reading

- *The Shepherd's Life* by James Rebanks — [read a review][rebanks]
- *H is for Hawk* by Helen Macdonald — [read a review][macdonald]
- *Landmarks* by Robert Macfarlane — [read a review][macfarlane]

[rebanks]: https://example.com/reviews/shepherds-life
[macdonald]: https://example.com/reviews/h-is-for-hawk
[macfarlane]: https://example.com/reviews/landmarks

Output

Currently Reading

The Shepherd's Life by James Rebanks — read a review
H is for Hawk by Helen Macdonald — read a review
Landmarks by Robert Macfarlane — read a review