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.
Pasting from Word, Docs and Notion
The clipboard carries more than the text you see. When you copy formatted content, the system puts a plain text flavour and an HTML flavour on it, and the second is a complete description of the formatting. Pasting into the box reads that flavour rather than the plain one, so headings, links, lists and tables all survive.
| Source | What it puts on the clipboard | What arrives here |
|---|---|---|
| Microsoft Word | HTML wrapped in conditional comments, Mso classes and an Office namespace | Just the fragment, with the Office wrapper removed |
| Google Docs | Everything inside a styled <b> with inline font declarations on each span | The structure, without the inline styling |
| Notion | Clean HTML with its own class names | Converts almost exactly |
| A web page | Whatever the page uses, including its layout wrappers | Headings, links and lists; layout divs are dropped |
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.What HTML becomes
| HTML | Markdown | Note |
|---|---|---|
<h1> to <h6> | # to ###### | Or underlined for H1 and H2 if you prefer |
<strong>, <b> | **text** | |
<em>, <i> | *text* | |
<del>, <s> | ~~text~~ | GitHub-flavoured, not in the original spec |
<a href> | [text](url) | Can be stripped to plain text instead |
<img> |  | The file itself is not copied — only the address |
<ul>, <ol> | - or 1. | Nesting is preserved by indentation |
<table> | Pipe table | Only if the table is rectangular; merged cells have no equivalent |
<pre><code> | Fenced block | Contents kept verbatim |
<blockquote> | > | Nested quotes keep their depth |
<input type=checkbox> | - [ ] or - [x] | Task list syntax |
<div>, <span> | Dropped | They carry no meaning to preserve |
Characters that mean something in Markdown
Markdown treats * _ ` [ ] # > as syntax. Text that contains them literally will render as formatting somewhere down the line, and the failure is silent — the file looks fine until it is displayed:
| In the HTML | Unescaped | What it renders as |
|---|---|---|
file_name_here.txt | file_name_here.txt | filenamehere.txt — the underscores became italics |
2 * 3 = 6 | 2 * 3 = 6 | A bullet point, if it starts a line |
[draft] | [draft] | A broken link reference |
# not a heading | # not a heading | An H1 |
Escaping is on by default because the alternative fails quietly. Turn it off when the source is already Markdown-aware and you want the characters passed through untouched.
Frequently asked questions
Why are there backslashes in the output?
Those escape characters that Markdown would otherwise read as formatting. A filename like file_name.txt becomes file\_name.txt so the underscores stay underscores rather than turning the middle into italics. Untick the escape option if your text is already written for Markdown.
Can I paste straight from Word or Google Docs?
Yes. Copy the formatted text and paste it into the box — the clipboard carries an HTML version alongside the plain text, and that is what gets converted. Word’s conditional comments and Office namespace, and the styled wrapper Google Docs adds, are stripped first so only the structure remains.
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: