HTML to Markdown Converter

Why converting HTML to Markdown is the harder direction

Markdown to HTML is a widening conversion — every Markdown construct has an HTML equivalent, so nothing has to be thrown away. HTML to Markdown is the opposite: HTML can express things Markdown simply cannot, and every converter has to decide, element by element, whether to translate, to unwrap, or to give up and leave raw HTML in the output. Get those decisions wrong and you end up with either a document full of `<div>` soup or a document that has quietly lost half its structure.

This page runs turndown, which makes those decisions the way most people expect. Elements with a Markdown equivalent are translated: headings become ATX (`## Heading`, never the underline style, because ATX survives being copied around); `<pre><code>` becomes a fenced block rather than an indented one, so it can carry a language tag; `<em>`, `<strong>`, `<a>`, `<img>`, `<blockquote>`, `<ul>`, `<ol>`, `<hr>` and `<code>` all map cleanly. Elements that are pure presentation — `<div>`, `<span>`, `<font>`, anything carrying only a class or a style — are unwrapped, keeping their contents and discarding themselves. Script, style, noscript and template blocks are removed outright, because their contents are code that would otherwise land in the document as prose.

One extra step happens on the way out: characters that mean something in Markdown are escaped. A literal asterisk in the source HTML becomes `\*` so it does not turn into emphasis when the Markdown is rendered again, and the same goes for underscores, backticks and the leading characters that would start a list or a heading. It looks noisy in the output and it is the difference between a document that round-trips and one that quietly changes meaning.

What survives, what is unwrapped, and what disappears

The table below covers the elements that come up in practice. The short version: semantics survive, presentation does not, and code is removed rather than pasted as text.

The jobs this tool exists for

Migrating content out of a CMS is the big one. A WordPress, Contentful or Confluence export is HTML wrapped in layers of layout divs and inline styles, and the destination — a docs repository, a static site generator, a wiki — wants Markdown files in version control. Converting strips the scaffolding and leaves content whose diffs are readable, which is the entire reason to move to Markdown in the first place.

Documentation reuse is the second. You want a third-party API's reference table in your own docs, or a Stack Overflow answer in a runbook, or the release notes from a vendor's changelog page in your internal wiki. Copying rendered content into a Markdown file normally means retyping the table by hand; copying the HTML and converting keeps the table, the code blocks and the links intact. The third is preparing text for tools that read Markdown: issue trackers, chat platforms, and increasingly the context you paste into an LLM, where Markdown is both smaller and less ambiguous than the equivalent HTML.

Two practical tips. If the source markup is minified or chaotically indented, running it through the HTML Formatter first makes it far easier to see what you are actually copying — the conversion itself does not care, but you will. And if you only want a fragment, select and copy just that subtree rather than the whole page; converting an entire modern web page includes its navigation, cookie banner and footer as lists of links. When you need the return trip, Markdown to HTML renders the result back with GitHub Flavored Markdown support.