Markdown was designed to be readable before it is converted

A tool released on 17 December 2004

John Gruber's Markdown project page dates the tool's public release, version 1.0.1, to 17 December 2004, distributed as a small Perl script alongside a syntax description; Gruber's own site archive lists that release, and a companion licensing post, under that same date. The page states plainly what Markdown is: 'two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML'. That pairing matters. Markdown was never only a way to produce HTML; it was, by design, a way to write a document that did not need to be converted to be legible.

Readable before it is rendered

The original syntax specification is explicit about the priority: 'The overriding design goal for Markdown's formatting syntax is to make it as readable as possible', so 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'. The syntax borrows its conventions from plain-text email: an asterisk for emphasis, a blank line between paragraphs, a line of dashes under a heading. None of these marks require a renderer to be understood by a person reading the raw file, which is a different design target from a markup language such as HTML, or a binary document format, both close to unreadable without their intended application.

What the original description left open

Gruber's page describes syntax through examples and prose, not a formal grammar. That choice is part of what let Markdown spread: nearly any language could implement a converter from a short description, and working ones appeared quickly. It is also what let Markdown drift. A decade of independent implementations, discussed at length in the CommonMark project's own account of Markdown's history, meant that a document with unusual nesting, an ambiguous list, or mixed HTML and Markdown lines could render differently depending on which tool opened it. The original page does not claim to resolve every edge case, and no test suite accompanied the 2004 release to check one implementation against another. Plain text outlived the tools built on top of it precisely because the format asked so little of any single implementation; the same minimalism is why Markdown is now a family of dialects rather than one fixed behaviour.

• Does the destination tool support the specific Markdown dialect the source file was written in, including tables and footnotes if used?
• If the tool disappears, can the document still be read and edited as plain text without it?
• Does the workflow depend on exact rendering, such as nested lists or line breaks, that varies between implementations?

Markdown's bet was that legibility as plain text mattered more than precise, guaranteed rendering, and two decades on that bet looks sound: the format is still readable in a bare text editor with no tool installed at all, which is more than can be said for most word-processor formats from the same year.