Markdown Preview

A Markdown preview shows what your Markdown will look like when rendered. The tool above runs the parser in your browser using a CommonMark-compatible engine; nothing leaves your machine.

What the preview renders

The standard Markdown features (see markdown cheat sheet for the full syntax):

• Headings (#, ##, ###, etc.)
• Emphasis (*italic*, **bold**)
• Lists (ordered and unordered, nested)
• Links and images
• Code (inline and fenced blocks)
• Blockquotes
• Horizontal rules
• Tables (GFM extension)
• Task lists (GFM extension)
• Strikethrough (GFM extension)

Most modern Markdown parsers handle this set. CommonMark plus GFM is the de facto standard.

Parser variation

The same Markdown rendered by different parsers can produce slightly different HTML. Examples:

• Underscore in the middle of a word. do_this_thing — does it become do<em>this</em>thing? Strict CommonMark says no (the underscores aren’t word boundaries); some older parsers say yes.
• Indentation in nested lists. 2 spaces vs 4 spaces. Stricter parsers require specific indentation; lenient ones accept either.
• Code block language hints. Standard for syntax highlighting; specific languages supported vary by parser.
• Smart quotes. Some parsers convert "text" to "text"; some don’t.
• Em-dash / en-dash conversion. -- to –, --- to —. Optional.

For documents that need to look the same everywhere, stick to the most universally-supported subset. Test in the actual target renderer.

CommonMark vs GFM vs other flavors

GFM is the dominant practical flavor — what most users encounter daily. CommonMark is the safer “render anywhere” subset.

Code highlighting

Fenced code blocks with a language hint:

```python
def hello():
    print("Hello, world!")
```

Whether the preview applies syntax colors depends on whether the parser is paired with a highlighter (highlight.js, Prism, Shiki). The tool above doesn’t include one — code blocks render in plain monospace, as they would in any renderer without a highlighter.

The language identifier (“python”) is conventionally lowercase. Common identifiers: python, javascript (or js), typescript (ts), bash, sh, json, yaml, html, css, sql, go, rust, c, cpp. Some highlighters accept aliases; some don’t. When in doubt, use the canonical name.

Math rendering

$E = mc^2$

If your preview supports math (via KaTeX or MathJax), $...$ produces inline math and $$...$$ produces block math. The tool above doesn’t render math; the dollar-sign source shows as plain text.

Math support varies more than other extensions — GitHub added it in 2022; Notion has had it; most static-site generators support it via plugin. Don’t assume math rendering when distributing Markdown to unknown destinations.

What preview doesn’t show

• Frontmatter. YAML/TOML metadata at the top is consumed by the build tool, not the Markdown renderer. Preview shows it as part of the document or strips it.
• Per-renderer extensions. Mermaid diagrams, custom shortcodes, MDX components — none render in a generic Markdown preview.
• Theme and styling. The HTML is rendered, but the CSS that styles it on the destination site isn’t. The preview gives a typographic shape, not the final visual.
• Build-time interpolation. Templating systems (Jekyll’s Liquid, Hugo’s templates, Astro’s expressions) produce final output that doesn’t match the source.

Live preview vs published

A live preview shows the document as the parser sees it. The published version may differ in:

• CSS. Site styles affect headings, links, code blocks visually.
• Plugin output. Some sites run pre/post-processing that changes content.
• Markdown extensions. The destination may support more or fewer extensions than the preview.

Always preview in the target environment for final review. The tool above is a quick-iteration check, not the final word.

Common pitfalls

• Misreading \n vs blank line. Markdown ignores single newlines (treats them as soft line breaks); blank lines separate paragraphs. A “single line of prose with internal newlines” renders as one paragraph in most parsers.
• Indentation inside list items. Continuing a paragraph inside a list item requires indentation matching the list-item content. Wrong indentation breaks the list.
• Missing language hints. Code blocks without language hints don’t get syntax-highlighted. Add the hint — even text is better than nothing.
• HTML inside Markdown. Most parsers allow it (CommonMark passes it through); some sanitize. If you rely on raw HTML in Markdown, verify the destination renderer accepts it.
• Special-character escaping. Inside code blocks, special characters are literal. Outside code blocks, characters like *, _, <, & may need escaping.

For the syntax reference, see markdown cheat sheet.