Markdown to HTML Converter

What a Markdown converter actually has to get right

Markdown looks like a format you could convert with a handful of regular expressions, and that impression survives right up until the first document that matters. Real Markdown has fenced code blocks whose contents must not be interpreted as Markdown, nested lists whose indentation determines depth, link reference definitions that appear hundreds of lines away from the links that use them, raw HTML that has to pass through untouched, and a specification — CommonMark — that took years to write precisely because every naive implementation disagreed with every other one on the edge cases.

This page runs marked, a full CommonMark implementation with the GitHub Flavored Markdown extensions layered on top. That matters most for the things people actually paste: a README with a pipe table, a changelog with task-list checkboxes, a documentation page with fenced code blocks tagged by language. Each of those is an extension rather than core Markdown, and a converter that only implements the original 2004 syntax will silently render your table as a paragraph full of pipe characters.

The output is plain, semantic HTML with no wrapper elements, no class names of its own and no inline styles — `<h2>`, `<p>`, `<ul>`, `<table>`, `<pre><code class="language-bash">`. That makes it safe to drop into a template that already has a stylesheet, and it makes the language class on code blocks usable by whatever syntax highlighter your site already loads. If you want the result indented for reading rather than for shipping, run it through the HTML Formatter afterwards.

GitHub Flavored Markdown, element by element

The table below is the practical reference: what you write, what comes out, and whether the GFM toggle is required for it. Everything above the GFM line is core CommonMark and converts with the toggle in either position; everything below it depends on the extensions being enabled.

Where this conversion comes up

The commonest reason is a content management system that never learned Markdown. You write documentation, release notes or a knowledge-base article in Markdown because that is what your repository speaks, and the CMS field wants HTML. Paste, convert, copy — and because the output has no styling of its own, it inherits the site's typography instead of fighting it.

The second reason is email. Marketing platforms and transactional-email templates take HTML, and writing a changelog email as HTML by hand is miserable. Draft it as Markdown, convert, and paste the fragment into the template's body slot. The third is previewing: you want to know what a README will look like before you push it, or to check that a table you hand-wrote is actually parsed as a table rather than as a paragraph. The GFM toggle turns that into a diagnostic — if the table only renders with GFM on, it will not render on a platform that runs strict CommonMark.

A caution worth repeating: converting is not sanitizing. Markdown deliberately allows raw HTML, so a document from an untrusted author can carry a `<script>` tag or an `onerror` attribute straight through this converter into the output. That is correct behaviour for a converter and dangerous behaviour for a web page, so run the result through a sanitizer before rendering user-submitted content. When you need the opposite direction — HTML you already have, turned back into Markdown — HTML to Markdown is the return trip, and the two round-trip cleanly for ordinary documents.