Markdown is a lightweight markup language designed to be read as plain text while carrying enough structural information to render as formatted HTML. Created by John Gruber in 2004, its core insight was that the conventions people already used in plain-text emails and Usenet posts — asterisks for emphasis, hash marks for headings, greater-than signs for quotes — could be formalized into a consistent syntax. The goal was never to replace HTML, but to remove the friction of writing it: no angle brackets, no closing tags, no visual noise obscuring the content.

That readability-first design is why Markdown dominates documentation. A README.md on GitHub is readable both as raw text on disk and as rendered HTML in the browser. Wikis, issue trackers, chat applications (Discord, Slack), and static site generators (Hugo, Jekyll, Astro) all accept Markdown because it lowers the barrier to formatted content — you don't need to know HTML to write a bulleted list or a code block, but the output is proper, semantic HTML.

For years, Markdown's biggest weakness was its lack of a formal specification. Gruber's original description was ambiguous on edge cases, and different parsers resolved those ambiguities differently — a document that rendered correctly on GitHub might break on a local preview tool. The CommonMark project (launched 2012, specification released 2014) fixed this by defining a precise, testable specification for Markdown's syntax, backed by a reference implementation and a conformance test suite of over 600 examples.

CommonMark doesn't define every feature people associate with Markdown — tables, strikethrough, task lists, and footnotes are extensions not part of the core spec. Instead, it provides a stable, interoperable base that extension builders can layer on top. When a tool claims CommonMark compliance, it means its parser passes the conformance suite and handles the core constructs — headings, paragraphs, lists, blockquotes, code blocks, links, images, emphasis, and inline code — identically to every other compliant parser.

GitHub Flavored Markdown (GFM) is the most widely used extension set. It adds tables, task lists, strikethrough, and auto-linked URLs and issue references on top of CommonMark. If you've ever written a GitHub issue with a checklist or a table, you've used GFM. Because GitHub's rendering is so visible, GFM's behavior is often mistaken for "standard Markdown," but a plain CommonMark parser will render |---| table syntax as literal text.

Pandoc's Markdown is the most feature-rich academic and publishing-oriented flavor, adding footnotes, citations, math notation, definition lists, and metadata blocks. Other environments have their own conventions: GitLab's Markdown adds multi-line blockquote syntax and plant diagrams; Reddit's Markdown is a GFM variant with its own link and spoiler extensions. The practical implication is that Markdown is portable for basic content — headings, lists, bold, italic — but advanced features require knowing which flavor your target platform supports.

A live Markdown preview is a deceptively simple application: parse the input text into an abstract syntax tree (AST), render the AST to HTML, and display the result. The challenge is doing it responsively. Re-parsing and re-rendering on every keystroke is fine for small documents but becomes janky with large files, because full parsing is O(n) and the DOM update it triggers can be expensive. Production editors use debouncing (re-render only after typing stops), incremental parsing (re-parse only the changed region), or virtualized rendering (only render the visible portion) to keep the preview smooth.

The preview pane itself must handle the HTML safely — a Markdown renderer that naively inserts its output into the DOM is vulnerable to XSS if the Markdown contains raw HTML. The safe pattern is to sanitize the rendered HTML (stripping script tags, event handlers, and javascript: URLs) before insertion, or to render inside a sandboxed iframe that isolates the preview from the host page. Syntax highlighting for fenced code blocks adds another layer: the code is tokenized and wrapped in spans with CSS classes, a process that can be delegated to a library like highlight.js or Shiki.

XSS prevention is the most important security concern in any Markdown renderer that accepts untrusted input. Markdown intentionally allows raw HTML to pass through, which means a malicious document can contain <script>tags, <img onerror> handlers, or <a href="javascript:..."> links. A safe renderer sanitizes the HTML output — either by stripping dangerous elements and attributes entirely, or by parsing the HTML and reconstructing it from a whitelist of safe tags and attributes. Libraries like DOMPurify implement this whitelist approach and are the standard defense.

Markdown's real power emerges in documentation workflows. Static site generators render Markdown to HTML at build time, producing fast, cacheable documentation sites. Content management systems store Markdown in databases and render it on demand. API documentation tools like OpenAPI use Markdown for endpoint descriptions that render as formatted text in interactive docs. The common thread is that Markdown is an authoring format — optimized for humans writing content — that gets compiled to HTML for consumption, whether by a browser, a PDF generator, or an e-reader.