Markdown Preview

DEVELOPER GFM MARKDOWN PREVIEW WRITER

About this tool

Type Markdown on the left, see HTML preview on the right. GitHub-flavored: headings, lists, tables, code blocks, task lists. In-browser, no signup.

Live Markdown to HTML preview. GitHub Flavored Markdown: tables, task lists, fenced code, strikethrough. In-browser, no signup.

RT-DEV-063 · Developer Tools · Reviewed May 2026

Markdown source

Rendered HTML preview

0 / 50,000 characters · 0 words

All parsing runs in your browser. No text is sent to our servers. Inline HTML in source is escaped, not rendered (XSS-safe by design).

How to Use the Markdown Preview

Type Markdown on the left

Use standard Markdown syntax: headings (#, ##), bold (**), italic (*), links ([text](url)), code blocks (```), lists (-, 1.), task lists (- [x]), tables (| col |), blockquotes (>), horizontal rules (---).

See the live preview

The right pane renders your Markdown as HTML in real time, debounced at ~120 ms. Switch between side-by-side and stacked layouts for narrower screens.

Load a sample

Pick a sample from the dropdown — kitchen sink (every feature), AI prompt template, or changelog. Useful for testing the parser before pasting your real content.

Copy or download

Copy the rendered HTML for paste-into-CMS workflows, or download as a self-contained .html file with basic styling. Your text never leaves the browser.

Markdown — Twenty-Two Years of Plain-Text Writing That Renders

John Gruber and Aaron Swartz published the original Markdown specification in March 2004 with a deceptively simple goal: a markup format that should be readable as plain text AND convert cleanly to HTML. Two decades on, that constraint has been validated by adoption: GitHub, GitLab, Notion, Obsidian, Bear, Discord, Reddit, Slack, Trello, Substack — every modern writing-adjacent tool either uses Markdown natively or accepts it as input. The format won because the constraint was right.

The format itself is intentionally minimal. Headings are # characters. Bold is double-asterisk. Italic is single. Lists are dashes or numbers. Links are bracketed text followed by parenthesised URLs. Code blocks are fenced by triple backticks. That is essentially the whole specification — the rest is convention and a handful of edge cases. The minimalism is the feature, not a limitation. Anything more elaborate (custom components, complex layouts) falls back to raw HTML, which most parsers happily honour.

"Markdown deliberately covers ~95% of what most writers need. The remaining 5% — complex layouts, custom components, mathematical notation — was never the goal. The goal was a format you can read in plain text while it still converts to clean HTML."
— Daring Fireball, John Gruber's original Markdown spec, 2004

CommonMark and GitHub Flavored Markdown

The early years of Markdown were dialect-fragmented. Gruber's original implementation was ambiguous on edge cases, and a dozen parser implementations diverged. In 2014 a group including Jeff Atwood (Stack Overflow), David Greenspan, and John MacFarlane published CommonMark — a formal specification that nailed down the ambiguous cases. Most modern Markdown engines conform to CommonMark today. On top of CommonMark, GitHub Flavored Markdown (GFM) added the extensions that became ubiquitous: tables, task lists (- [x] and - [ ]), strikethrough (~~text~~), autolinks for bare URLs, and language hints on fenced code blocks (```javascript). When developers say "Markdown" today, they usually mean CommonMark + GFM. That is what this tool implements.

What this tool does not implement: footnotes (Markdown Extra), MathJax/KaTeX for LaTeX math, Mermaid diagrams, custom directives (MDX), or definition lists. These are extensions beyond GFM and are inconsistently supported across parsers. If you need them, look for a specialised renderer or use the parser embedded in your destination platform (Notion, Obsidian, etc.).

Why we wrote our own parser

A robust open-source Markdown parser (marked.js, ~50KB) exists and could have been vendored into the RECATOOLS asset folder per platform conventions. Instead this tool ships with a focused 250-line in-house parser. Two reasons. First, bundle size: a custom parser tailored to GFM-subset adds about 8 KB to the page versus 50 KB for a general-purpose library. Second, XSS safety: the in-house parser deliberately escapes raw HTML in source rather than honouring it. That eliminates a whole class of risks — paste an attacker-crafted Markdown string into a general parser and you may get a script tag in the output; paste it here and you get escaped text. For a Markdown preview tool with no trust assumptions about input, the safer default is right.

Performance is a side effect of the focused scope. Even on a 50,000-character document (roughly a 20-page write-up) the parser renders in under 20 ms on modern hardware. The 120 ms input debounce keeps typing responsive while avoiding wasteful re-renders during a fast burst of keystrokes. There is no compilation step, no virtual DOM, no framework — just a tight loop over the source text. Open DevTools and watch the timing if you are curious.

10 Things to Know About Markdown

Markdown is 22 years old. Created by John Gruber and Aaron Swartz in 2004. The original goal: a writing format that is readable as plain text AND converts cleanly to HTML.

CommonMark — the standard. After years of dialect drift, CommonMark (2014) became the formal specification. Today most parsers conform to CommonMark plus GitHub Flavored Markdown extensions.

GFM added tables + task lists. GitHub Flavored Markdown extended CommonMark with tables, task lists (- [x] / - [ ]), strikethrough (~~text~~), autolinks, and code-block language hints — all now ubiquitous.

Used by everyone. GitHub, GitLab, Notion, Obsidian, Bear, Discord, Reddit, Slack, Trello — every modern writing-adjacent tool either uses Markdown natively or accepts it.

Two spaces = line break. A subtle gotcha: a soft line break in source becomes a space in output. To force a hard `<br>`, end the line with two trailing spaces. Most parsers also accept a backslash.

Code blocks have language hints. Fenced code blocks with a language identifier (```javascript) let syntax highlighters tint the code without inline tags. Even without a highlighter, semantic value persists.

It is purposely limited. Markdown deliberately covers ~95% of what most writers need. Anything more specialised (complex layouts, custom components) falls back to raw HTML — which most parsers honour.

AI prompts love it. Markdown is the de-facto formatting language for LLM prompts and outputs. Frameworks like CRAFT and CO-STAR rely on Markdown headings to separate context, role, action, and format sections.

XSS is a real risk. A naive parser that honours raw HTML in source can be exploited for XSS. Safe parsers escape text content and either reject or sanitise inline HTML. This tool escapes everything — Markdown-only by design.

In-browser parsing is fast. Even on long documents (~50K characters), a focused parser renders in under 20 ms on modern hardware. Live preview is genuinely cheap when implemented carefully.

Frequently Asked Questions

CommonMark plus the most-used GitHub Flavored Markdown extensions: tables, task lists (- [x] / - [ ]), strikethrough (~~text~~), autolinks for bare http(s) URLs, and code blocks with language hints. Lists nest. Blockquotes nest. Tables support column alignment with :-: / -: / :-. Raw HTML in source is escaped (not honoured) — by design, to keep the tool XSS-safe.
By design. Most Markdown parsers honour inline HTML, which makes them a vector for XSS attacks if untrusted text reaches the parser. This tool escapes all HTML in the source so what you type is what you see. If you want to mix HTML and Markdown, paste your final HTML directly into a CMS — do not rely on this tool as a final renderer.
No. The entire parser runs in your browser. Your input, the rendered HTML, the copy and download actions — none of it touches our servers. No analytics on input text. You can verify this in DevTools: only the static asset bundle loads, nothing else.
Yes — the Download button packages the rendered HTML into a minimal self-contained .html file with basic styling (system font, readable line-height, padded code blocks, simple table styling). Drop the file anywhere it can be opened in a browser.
A few possibilities: (1) you may be using a Markdown extension this parser does not cover, such as footnotes, MathJax, or Mermaid diagrams; (2) syntax may be slightly off — Markdown is unforgiving about blank lines around lists, code blocks, and tables; (3) raw HTML is intentionally escaped, not rendered. The kitchen-sink sample shows every feature this tool supports; if your input is not in there, it is not parsed.
Yes — tested up to 50,000 characters (roughly a 20-page document). Live preview is debounced at ~120 ms so typing remains smooth. For documents over 50K characters, paste in chunks. The parser is single-pass and avoids re-rendering anything that has not changed.
Markdown Extra is an older extended flavour by Michel Fortin that added definition lists, footnotes, and id attributes on headings. It predates CommonMark. Most modern parsers (including GitHub, Notion, Obsidian) implement CommonMark plus GFM rather than Markdown Extra — that is what this tool follows.
Absolutely — it is one of the most common use cases. Markdown is the de-facto formatting language for LLM prompts: headings to separate sections (## Context, ## Role, ## Task, ## Format), bullet lists for criteria, fenced code blocks for examples or templates. Build your prompt here, preview the structure, then paste the source Markdown into ChatGPT / Claude / Gemini. See our AI Prompt Builder tool for guided prompt frameworks.
Yes — Markdown is encoding-agnostic. Use it freely with Chinese, Bahasa Indonesia, Bahasa Malaysia, Tamil, Tagalog, Vietnamese, Thai, or any other script. The parser does not care about character set. The only tip: tables in non-Latin scripts may need slightly more generous column widths in the rendered output because each Chinese character is roughly 1.5× the visual width of a Latin character at the same font size.
Two reasons. First, the AI Prompt Builder (RT-DEV-062) hard-linked to a "markdown-preview" tool that did not yet exist — an SEO and UX gap. Shipping this tool closes that loop. Second, prompt-engineering workflows increasingly need round-trip Markdown editing: build the prompt in Markdown, preview the structure, paste into the AI, get a Markdown reply, preview it again. This tool is the lightweight, no-signup viewer for that loop.

Markdown Preview