Convert HTML into clean Markdown - headings, links, lists, tables, code blocks and inline formatting. Useful when you're moving content into a documentation system, a static site generator, or anywhere that stores prose as Markdown rather than markup.
HTML to Markdown
LiveWhat converts, and what doesn't
| Converted | Passed through as HTML |
|---|---|
Headings h1–h6 | Anything Markdown has no syntax for |
| Links and images | Nested tables |
| Bold, italic, inline code | iframe, video, embeds |
| Ordered and unordered lists | Elements with meaningful classes or IDs |
| Blockquotes, code blocks, rules | Form controls |
| Simple tables | Inline styles |
Markdown is deliberately a smaller language than HTML, so a faithful conversion isn't always possible. Where there's no equivalent, leaving the original HTML inline is the honest outcome - every Markdown renderer worth using passes raw HTML through, so the result still displays correctly.
Why convert at all?
- Moving into a static site generator - Hugo, Jekyll, Astro and Next.js all take Markdown as their content format.
- Documentation systems - most wikis, README files and docs platforms are Markdown-native.
- Version control - Markdown diffs cleanly in Git; HTML diffs are noisy and hard to review.
- Portability - Markdown is plain text, so content outlives whatever CMS it started in. That's the strongest argument for it.
Common mistakes
/about in the source means something different once the content lives at a new address. Check every internal link after a bulk migration - this is where conversions quietly break.<strong> was being used as a heading, or that a list was really a table. Read the result before committing it.Frequently asked questions
Is anything I paste uploaded?
No. The conversion uses your browser's own HTML parser and runs entirely locally, with no server request and nothing stored. That matters when you're converting unpublished drafts or a client's content.
Why is some HTML still in the output?
Because Markdown has no equivalent for it. Embeds, nested tables and elements carrying meaningful attributes have no syntax to convert into, so the original tag is kept. Markdown renderers pass raw HTML through, so it still displays - and keeping it is more honest than silently discarding content.
Which Markdown flavour does this produce?
GitHub-Flavored Markdown, which is the de facto standard - it's what GitHub, GitLab, most static site generators and most documentation platforms expect. The main extensions it relies on are tables and fenced code blocks.
Can it convert Markdown back to HTML?
Not in this direction - it's one-way. That's usually fine, because the workflow is normally a migration: you convert once, then edit the Markdown from then on. If you need the reverse, whatever platform stores your Markdown renders it to HTML for you already.
Should I strip links when converting?
Only if you're extracting text for a different purpose - a summary, a transcript, or content going somewhere links don't work. For a genuine migration, keep them: internal links are part of your site structure, and rebuilding them afterwards is far more work than fixing the paths.
Does this handle very large documents?
It parses in your browser, so practical limits depend on your device rather than a server timeout. A long article is no problem; an entire site dumped into one paste may be slow. Converting page by page also makes the output easier to review, which you should be doing anyway.
Related tools
See the full list of Generators, or try: