Markdown to HTML Converter
Paste markdown on the left, see rendered HTML on the right.
Supports headings (# to ######), bold, italic, inline and fenced code, links, blockquotes, and ordered/unordered lists.
How is this calculated?
This is a tiny in-browser converter, not a full CommonMark engine. It supports headings, emphasis, inline code, fenced code blocks, links, blockquotes, ordered and unordered lists. Input is HTML escaped before transformation, so pasted HTML appears as literal text. For full CommonMark fidelity, use a library such as marked, markdown-it, or remark.
About Markdown to HTML
Markdown to HTML converters take the lightweight plain-text format John Gruber introduced in 2004 and turn it into the equivalent HTML markup. This tool implements a CommonMark-aligned subset entirely in the browser so you can preview README files, blog posts, and documentation without copy-pasting into a third-party site.
The conversion runs through a single-pass tokenizer that recognises block constructs first and then applies inline rules within each block. Everything stays on the client, so you can drop in unpublished drafts, internal release notes, or proprietary technical documents without sending text to any server. The output HTML is plain semantic markup that drops cleanly into a CMS rich-text field, a static-site generator template, or an email composer.
How it works
The parser is a single-pass line scanner: it identifies block-level constructs (fenced code, headings, blockquotes, ordered and unordered lists, paragraphs), then applies inline patterns within each block.
For each line:
if line starts ``` emit <pre><code> ... </code></pre>
if /^#{1,6} / emit <hN> ... </hN>
if /^> / emit <blockquote><p> ... </p></blockquote>
if /^\d+\. / or /^[-*+] / emit <ol> or <ul> with <li>
else collect paragraph until blank line, emit <p> ... </p>
Inline:
`code`, **bold**, _italic_, [text](url)
- Escape first, then transform: input is HTML-escaped before inline patterns are applied. This blocks script injection from pasted HTML.
- Supported: ATX headings, bold (
**or__), italic (*or_), inline code, fenced code, links, blockquotes, OL, UL. - Not supported: GFM tables, task lists, strikethrough, autolinks, footnotes, definition lists, math, raw HTML pass-through.
Worked example
Input markdown:
- Source line:
# Welcome - Match: ATX heading level 1.
- Output:
<h1>Welcome</h1>. - Source paragraph:
This is **bold** and `code`. - Inline scan:
**bold**matches, replaced with<strong>bold</strong>. Backtick pattern wrapscodein<code>. - Output:
<p>This is <strong>bold</strong> and <code>code</code>.</p>. - Source list: three lines starting with
-. - Output:
<ul><li>...</li><li>...</li><li>...</li></ul>.
Markdown flavors compared
| Feature | CommonMark | GFM (GitHub) | Pandoc |
|---|---|---|---|
| Headings, bold, italic | Yes | Yes | Yes |
| Tables | No | Yes | Yes (pipe + grid) |
Task lists [ ] | No | Yes | No |
Strikethrough ~~ | No | Yes | Yes |
| Autolinks bare URLs | No | Yes | Partial |
Footnotes [^1] | No | No | Yes |
Math $...$ | No | Partial | Yes |
| YAML metadata block | No | No | Yes |
| Raw HTML passthrough | Yes | Filtered | Yes |
Common mistakes
- Mixing inline asterisks and underscores incorrectly.
__bold__works,_*mixed*_behavior varies between parsers. Stick to one style per project. - Forgetting blank lines around blocks. A list with no blank line above can get absorbed into the preceding paragraph by some parsers. Always separate block constructs with a blank line.
- Indenting code blocks incorrectly. Triple-backtick fenced code is more reliable than 4-space indentation, especially inside list items where indentation is already used for nesting.
- Expecting GFM tables to work everywhere. Tables, task lists, and strikethrough are GFM extensions. CommonMark-only parsers (and this tool) render them as literal text.
- Pasting curly quotes from Word. Smart quotes (
"") break many inline emphasis rules. Convert to straight ASCII quotes first. - Trusting raw HTML rendering for security. Most markdown engines (including this one's escape-first strategy) block HTML execution. For untrusted user input, sanitize the output HTML through DOMPurify before injecting it into a page.
- Relying on tight list spacing. A loose list (blank lines between items) gets wrapped paragraphs in many parsers; a tight list does not. Adding or removing one blank line can change vertical rhythm dramatically. Pick one style for the whole document.
- Forgetting the trailing space for hard breaks. A line break inside a paragraph requires two trailing spaces or a backslash at end of line in CommonMark. A single newline collapses to a space. This trips up writers used to plain-text editors.
Related tools and glossary
Frequently asked questions
What markdown flavor does this support?
A subset of CommonMark: ATX headings, bold, italic, inline code, fenced code blocks, links, blockquotes, and ordered or unordered lists. It does not implement full GitHub Flavored Markdown (no tables, task lists, strikethrough, autolinks) or Pandoc extensions (no footnotes, citations, definition lists). For full GFM use marked or markdown-it.
How is input safety handled?
Input is HTML-escaped before markdown transformation, then the markdown patterns are re-applied. Pasted HTML appears as literal text rather than executing, so the converter cannot be used to inject script tags. Link href values are not sanitized; do not paste untrusted markdown into a context that renders the output.
What is the difference between CommonMark and GFM?
CommonMark (2014) is the spec that resolved the ambiguities in John Gruber's 2004 original markdown. GFM (GitHub Flavored Markdown) extends CommonMark with tables, task lists ([ ] and [x]), strikethrough, autolinks for bare URLs, and disallowed raw HTML. Pandoc adds another layer: footnotes, definition lists, citations, math, and YAML metadata.
Why does my output look different in GitHub?
GitHub uses GFM with custom CSS (the github-markdown-css project) plus syntax highlighting via Pygments-like rendering. Differences come from extensions (tables work in GFM but not here), CSS (margins, fonts, colors), and code highlighting (we output the language class but do not include a highlighter).
Can I copy the rendered HTML into WordPress or Notion?
Yes. The HTML source box outputs semantic tags (h1, p, ul, code, blockquote) with no inline styles or custom classes other than the language hint on code fences. Paste it into a WordPress block editor in Code editor mode, into Ghost's HTML card, or as raw HTML in an email template. Notion does not accept HTML directly; instead, render the markdown on the page and copy the rendered text, or use Notion's own markdown import.
Sources
- CommonMark (2014, current spec 0.31) A strongly defined, highly compatible specification of Markdown.
- GitHub (2024) GitHub Flavored Markdown Spec.
- Gruber, John (2004) Daring Fireball: Markdown, the original spec.
- Pandoc (2025) Pandoc User's Guide: Pandoc's Markdown.
