Markdown Html Converter

Convert Markdown to HTML and HTML back to Markdown, with a live preview — for moving content between a CMS, a README and an email.

Conversion runs both ways, and the two directions have different failure modes. Markdown to HTML is well defined. HTML to Markdown is lossy by nature: Markdown has no syntax for a colspan, a nested table or a styled span, so a converter has to decide what to keep as inline HTML and what to discard.

This page keeps the structures Markdown can express — headings, lists, tables, links, code blocks, blockquotes — and preserves the rest as inline HTML rather than silently deleting it. That makes it usable for the common job of turning a copied web page or a Word export into something a README or a wiki will accept.

Markdown is not one specification, and that is the source of most surprises. The original 2004 syntax had no tables, no strikethrough and no task lists; those arrived with GitHub Flavored Markdown, and CommonMark — the strict grammar most modern parsers implement — treats them as extensions rather than as part of the core. A table that renders cleanly in a GitHub README can therefore arrive in a wiki as a wall of pipe characters, and the same source file becomes two different documents depending on who reads it. The parser here runs with the GitHub extensions on, which is what a README, a GitLab issue or an Obsidian note expects, and is the flavour worth assuming unless the destination says otherwise.

Pasted HTML is rarely clean, and knowing what will be thrown away saves a round of confusion. A copy out of Word or Google Docs carries an inline style on every other word, mso-prefixed classes, and empty paragraphs standing in for vertical spacing — none of which Markdown has any way to express. What survives is the structure Markdown can name: headings, lists, tables, links, emphasis, code and blockquotes. Presentational markup is dropped rather than approximated with asterisks, which is what keeps the result readable instead of turning a styled document into noise. Nested lists are the part worth checking afterwards, because the indentation a converter emits and the indentation a particular renderer expects are not always the same number of spaces.

Two details matter before the output goes anywhere else. Converting to Markdown escapes the characters that would otherwise be read as markup, so an identifier written as some_name_here keeps its underscores instead of turning its middle into italics — the most common way a code sample is quietly corrupted in transit. Converting the other way does not sanitise anything: a script tag written into the Markdown source is rendered as a script tag, because stripping HTML would break the inline markup that Markdown deliberately permits. That is the correct behaviour for a converter, and it means the HTML side of this page is output to read and to paste, not output to inject straight into a page that renders untrusted input.

Line breaks are the smallest difference between flavours and the one that produces the most confusion. In the original syntax a single newline is not a break at all — the two lines join into one paragraph — and a hard break requires two trailing spaces, which are invisible and routinely stripped by editors that trim whitespace on save. GitHub Flavored Markdown treats a newline inside a paragraph as a break in comments and issues but not in every context, which is why the same text wraps differently in a comment box and in a README rendered from the same repository.