Markdown to HTML and back: a converter with a live preview
Paste Markdown and you see the finished page with clean HTML next to it. Paste HTML and you get Markdown fit for a README or a blog post. Both directions run in your browser: the text is never sent anywhere and never stored.
.md here — the file is read locally. CommonMark is supported in its typical scope plus the GFM extensions: tables, strikethrough, task lists.
Paste Markdown above — the HTML will appear here.
.html here — the file is read locally. Parsing goes through DOMParser, so it works with a fragment as well as a whole page.
Paste HTML above — the Markdown will appear here.
The text never leaves your browser — the conversion runs locally, with nothing sent to a server.
What exactly is supported
On the Markdown side — CommonMark in its typical scope plus the GFM extensions: headings with hashes and with underlining, paragraphs, horizontal rules; bulleted, numbered and nested lists, in both tight and loose form; task lists in square brackets; blockquotes, including lazy line continuation; fenced code with a language name and indented code; GFM tables with column alignment; links, images, autolinks, reference links defined at the bottom of the document; bold, italic, strikethrough, inline code, escaped characters, hard line breaks. On the HTML side parsing goes through the browser's own DOMParser, so both a fragment and a whole page with a head work. Tables with merged cells do not carry over to Markdown — there is no such syntax there, so they stay as tags and the tool says so. What is deliberately absent: syntax highlighting in code blocks, footnotes, formulas and the directives of particular static site generators. That is no longer Markdown but the dialect of one specific tool.
One line break: two different Markdowns
The most common source of discrepancies between converters is precisely the single line break inside a paragraph. Under CommonMark it is an ordinary space: two lines are glued into one paragraph. That is how Pandoc, documentation generators and most static sites behave. GitHub does the opposite in comments, issue descriptions and reviews: every break becomes a br tag. That is exactly why text that looked fine in an issue congeals into one solid paragraph once moved into a README. The «A single line break is a br» checkbox switches between these two habits. By default the CommonMark rule applies.
Why the preview does not show everything that is in the HTML
By specification, Markdown allows HTML inside itself. That is convenient and at the same time means any pasted text may contain executable code. Popular online viewers put the result into innerHTML as it is. The marked library they are built on has had no built-in sanitisation at all since version four — a script tag from someone else's Markdown simply runs there. Here the preview is built from DOM nodes against a whitelist: script, iframe, object, event handlers such as onclick and links with the javascript: scheme never reach it, and the list of what was cut out is shown under the result. On the «HTML code» tab you see the full output with nothing removed — it is text, not a page, and it cannot be executed. HTML from the source can reach the preview only when you switch the corresponding checkbox on yourself. By default tags are escaped and shown as text.