Tools Guides
Developer Free No signup

Interactive Markdown Reference

Side-by-side Markdown syntax and rendered output with a live playground.

Loading tool…

About this tool

A comprehensive interactive reference for Markdown. Every syntax element is shown with its raw Markdown source alongside the rendered HTML output. Categories covered: Headings, Text Formatting (bold, italic, strikethrough, inline code), Lists (unordered, ordered, task lists), Links, Images, Fenced Code Blocks, Tables, Blockquotes, and Horizontal Rules. Click the 'Copy' button on any example to copy the markdown syntax directly to your clipboard. The Playground tab offers a split-pane editor with live rendered preview. A flavor selector (CommonMark, GitHub Flavored Markdown, Standard) labels which extensions apply.

How to use

  1. 1 Browse the Reference tab to see all Markdown syntax with rendered examples.
  2. 2 Filter by category using the dropdown.
  3. 3 Hover any code block and click 'Copy' to grab the syntax.
  4. 4 Switch to the Playground tab to type Markdown and see it rendered live.
  5. 5 Use the flavor selector to note GFM vs. standard differences.

Learning Markdown by seeing source and result together

Markdown is a plain-text formatting syntax that converts to HTML — you write **bold** and get bold, you write ## Heading and get a heading. The fastest way to learn it is not to memorise a rules list but to see each piece of syntax beside the exact output it produces. That's what this reference does: every example shows the raw Markdown on the left and the rendered result on the right, so the mapping between cause and effect is never ambiguous. A separate Playground tab lets you type freely and watch your own Markdown render live as you go.

What the reference covers

The cheat sheet is organised into nine categories, each with copy-ready examples:

  • Headings — one to six # characters set the level; # is the largest, ###### the smallest.
  • Text formatting**bold**, *italic*, ***both***, ~~strikethrough~~, and `inline code`.
  • Lists — unordered with -, ordered with 1., and task lists with - [ ] and - [x].
  • Links and images[text](url) for links, ![alt](url) for images, plus linked images.
  • Code — inline backticks and fenced blocks with triple backticks, optionally tagged with a language.
  • Tables, blockquotes, and horizontal rules — pipe-delimited tables, > quotes, and --- dividers.

A worked example: the difference one character makes

Look at the Text Formatting section. *word* renders as word — a single asterisk on each side means italic. Add a second asterisk, **word**, and you get word — bold. Stack three, ***word***, and it's both at once. The rendered column shows all three side by side, so the role of each asterisk is obvious. The same pattern explains a frequent beginner error: writing *bold* when you meant bold and being puzzled it came out slanted. Seeing the syntax-to-output pairing kills that confusion immediately.

CommonMark, GFM, and "standard" — what actually differs

Markdown has dialects, and the Playground's flavour selector labels three of them. Standard Markdown is John Gruber's original 2004 syntax. CommonMark is a strict specification that pins down the ambiguous corners of the original. GitHub Flavored Markdown (GFM) extends CommonMark with the features developers rely on daily: tables, task-list checkboxes, ~~strikethrough~~, and automatic linking of bare URLs. Several examples here are tagged "(GFM)" precisely because they don't exist in the original spec — if you paste a task list into a renderer that only supports plain Markdown, the checkboxes won't appear. Knowing which features are extensions saves you from "it works on GitHub but not in my tool" surprises.

How the live preview renders

The Playground uses a built-in Markdown parser that runs entirely in your browser — it reads your text line by line and converts headings, emphasis, lists, task lists, links, images, fenced code, tables, blockquotes, and rules into HTML in real time as you type. It is a focused, practical subset rather than a full specification engine, which is why it stays fast and needs no external library. One honest caveat: the flavour selector mainly serves to document which extensions apply; the preview already supports the common GFM features regardless of the selected label, so use the selector as a learning guide rather than expecting it to toggle behaviour.

Practical use cases

  • Writing README files and GitHub issues — check table and task-list syntax before committing.
  • Documentation and wikis that accept Markdown, where you want to confirm a fenced code block or blockquote looks right.
  • Forum and chat posts on platforms that support Markdown, drafting formatting in the Playground first.
  • Teaching yourself the syntax by copying an example, tweaking it, and watching the output change.

Tips that prevent broken formatting

  • Tables need a separator row. The line of dashes and colons (|:---|:--:|---:|) under the header isn't decorative — it tells the parser where the header ends and sets column alignment.
  • Leave a blank line around blocks. Headings, lists, and code fences render most reliably when separated from surrounding paragraphs by an empty line.
  • Close your code fences. A triple-backtick that's opened but never closed will swallow the rest of your document as code.
  • Use the Copy button on any example. Hover a source block and click Copy to grab the exact syntax instead of retyping and risking a typo.

Common mistakes

  • Expecting raw HTML or scripts to run. For safety the renderer escapes typed markup and only permits http, https, and mailto links — a javascript: URL is neutralised, not executed.
  • Assuming all renderers support GFM. Strikethrough, tables, and task lists are extensions; a minimal Markdown processor may ignore them.
  • Indenting list items inconsistently, which can turn a nested list into a code block in stricter parsers.

Privacy

Everything — the reference rendering and the live Playground — runs locally in your browser. Nothing you type in the editor is uploaded or stored on a server; the conversion happens on your device as you type.

Frequently Asked Questions

{# Alpine.js — self-hosted. (The previous jsdelivr CDN tag had a stale SRI integrity hash, so the browser refused to run it and window.Alpine was never defined — silently breaking every FAQ accordion and Alpine tool.) #}