Markdown to HTML

Convert Markdown to HTML instantly. Preview the rendered output or copy the raw HTML.

Markdown

or drop a file here

Convert Markdown to HTML in your browser

Markdown is a lightweight markup language created by John Gruber in 2004 that converts to HTML. This tool uses the marked library — the same parser used by GitHub READMEs and countless documentation generators — to render your Markdown to clean HTML. All processing happens in your browser; nothing is sent to a server. For the reverse, try HTML to Markdown or generate a table of contents with Markdown TOC Generator.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Checking how a document will render before publishing it.
Seeing exactly which HTML a parser emits, when a renderer downstream is sanitising something away.
Converting notes into markup for an email or a static page.
Working out why a construct is not rendering as you intended.
Generating HTML from a README for a project page.

How it works in practice

A worked example

A README has to become HTML for a project page, and you want to see the exact markup rather than a rendered approximation of it.

Input

| plan | seats |
|---|---|
| team | 12 |

Docs at https://example.com/docs and a snake_case_flag stays plain.

Output

<table>
<thead>
<tr>
<th>plan</th>
<th>seats</th>
</tr>
</thead>
<tbody><tr>
<td>team</td>
<td>12</td>
</tr>
</tbody></table>
<p>Docs at <a href="https://example.com/docs">https://example.com/docs</a> and a snake_case_flag stays plain.</p>

Two extensions are visible here and neither is in the original Markdown. The pipe table became a real table element with a head and a body, which only happens because this follows the GitHub dialect. The bare URL became a link without anyone asking for one, which is autolinking — convenient in a README and occasionally not what you want in prose. What did not happen is any styling or any wrapper: the output is a bare fragment, so the preview panel supplies its own stylesheet and your site will have to supply its own too.

The edge case that catches people

Asterisks and underscores are not interchangeable, and the difference only shows inside a word. Wrapping the middle of a word in asterisks produces emphasis; doing the same with underscores produces the literal underscores back. That asymmetry is deliberate and it exists for exactly the identifier in the example above — snake_case names would otherwise turn into italics halfway through, which was a real and constant annoyance in the years before the rule was written down. So an identifier is safe and a bare asterisk in prose is not.

When not to use this tool

Not as the conversion step in a publishing pipeline. A static site generator applies one dialect consistently, adds heading anchors, highlights code and wraps everything in your own template, and a paste through here is a snapshot that does none of that. The safety picture is also split in a way worth knowing: the preview runs inside an iframe with the sandbox attribute empty, so scripts cannot execute and cannot reach this origin, which makes hostile input safe to look at here. The HTML in the other panel has had nothing removed from it.

Frequently Asked Questions

Which Markdown dialect does this follow?: GitHub Flavored Markdown, which is CommonMark plus tables, strikethrough, task lists and autolinks. That matters because the original 2004 Markdown left many cases undefined and every implementation resolved them differently — CommonMark exists to make the edge cases testable.
Is the HTML output safe to insert into a page?: Only after sanitising. Markdown permits raw HTML by design, so a document containing `<script>` produces a script tag in the output. Any pipeline rendering user-supplied Markdown needs a sanitiser after the converter — the converter's job is translation, not safety.
Why does my single line break disappear?: Because Markdown treats a single newline as a space and needs a blank line for a new paragraph. Two trailing spaces or a backslash produce a `<br>`. GFM enables hard line breaks in some contexts like comments, which is why the same text behaves differently on GitHub than in a static site.
How are code blocks rendered?: As `<pre><code>` with a `language-xxx` class from the fence's info string. The converter does not highlight anything — that class is a hook for a highlighter like Prism or Shiki to act on afterwards, which is why unhighlighted output is correct rather than incomplete.
What does not survive conversion?: Anything dialect-specific: footnotes, definition lists, admonition blocks and front matter are extensions rather than standard Markdown, and each renderer supports a different subset. Front matter in particular passes through as literal text unless the pipeline strips it first.

Common errors and gotchas

Rendering untrusted Markdown and inserting the HTML without sanitising, which is an injection route.
Assuming one flavour, since tables, footnotes and task lists are extensions with varying support.
Using a single line break and expecting a new line, where most parsers need two spaces or a blank line.
Indenting a code block by three spaces rather than four, which makes it a paragraph.
Forgetting a blank line before a list, which joins it to the paragraph above.