Two ways of writing the same document
HTML names every part of a document with a tag. Markdown names the same parts with punctuation, and leaves anything it has no punctuation for as HTML. Converting one way drops the tags that have a shorter spelling; converting back puts them all in again.
<h1>Release notes</h1> → # Release notes — one heading, eleven characters shorter
The two are not the same size, though, and that is the interesting part. Markdown has no spelling at all for <kbd> or <details>, and tables are an extension rather than part of the original language — so this tool writes GitHub's table syntax when you ask for it and keeps everything else as literal tags rather than quietly losing it. Every conversion runs in this tab; no document is uploaded.
Why convert instead of retyping
A document that already exists is longer than it looks. Retyping a page as Markdown means re-reading every heading level, every list, every link address and every table cell, and the errors that creep in are the ones nobody notices: a level-three heading that became level two, a link that lost its query string, a table row that lost a column.
A converter gets all of those right by construction, because it reads the structure rather than the appearance. What it cannot decide is style — whether a bullet is a dash or an asterisk, whether links sit beside their text or collect at the bottom — and that is what the controls are for. Set them once to match the project you are pasting into, and the result needs no cleaning up.
The reverse direction earns its place for a different reason: it is how you find out what your Markdown actually says. A renderer shows you a picture of the document; the markup shows you the document.
What maps to what
The left column is what arrives, the right is what gets written. Read it in either direction — the two halves are the same table.
| HTML | Markdown |
|---|---|
| <h1>…</h1> | # … |
| <strong>…</strong> | **…** |
| <em>…</em> | _…_ |
| <code>…</code> | `…` |
| <pre><code class="language-ts"> | ```ts |
| <ul><li>…</li></ul> | - … |
| <blockquote>…</blockquote> | > … |
| <a href="…">…</a> | […](…) |
| <table>…</table> | | … | … | |
| <del>…</del> | ~~…~~ |
| <kbd>…</kbd> | <kbd>…</kbd> |
Tables and strikethrough are GitHub's additions rather than original Markdown, so both rows need that switch on — with it off, a table arrives as the text of its cells and nothing else. The last row is not Markdown in any version: <kbd> has no punctuation to become, so the tag is kept as written and the renderer at the other end passes it through.
Every control, and when to reach for it
Nine controls. Each one belongs to a direction, and the panel shows only the ones the direction you picked actually reads.
| Option | What it does | Reach for it when |
|---|---|---|
| GitHub Flavored Markdown | Adds tables, ~~strikethrough~~ and - [x] task lists to what gets written, and to what gets read. | Almost always. Turn it off only when the destination is a strict CommonMark renderer that would print the extensions as literal text. |
| Heading style | Writes # Title, or writes the title with a rule of = underneath it. | Setext suits a document of one or two heading levels and nothing deeper — it has no spelling below the second, which quietly falls back to hashes. |
| Bullet character | Chooses which of -, * and + starts an unordered list item. | Your project already picked one and a linter checks it. All three mean the same thing to every renderer. |
| Code blocks | Writes a fenced block, or indents the code by four spaces. | Fenced, unless something downstream predates fences. Indenting loses the language name — see below. |
| Emphasis | Chooses _ or * around emphasised text. Strong text is always **. | Your style guide has an opinion. Underscores read more clearly inside a word that also contains asterisks. |
| Links | Keeps each address beside its text, or replaces it with a number and lists every address at the end. | Referenced links keep long paragraphs readable when the same few addresses appear over and over. |
| Keep inline HTML | Leaves elements Markdown has no spelling for — <sub>, <kbd>, <details>, <figure> — as literal tags. | Leave it on unless the destination strips HTML. Turning it off replaces each tag with its bare text, which is not recoverable. |
| Line breaks | Turns every single newline into <br> rather than joining the lines into one paragraph. | The Markdown was written in a comment box or a chat client, where pressing return was meant to break the line. |
| Whole document | Wraps the markup in a <!doctype html> file with a character set, a viewport, and a title taken from the first heading. | You want a file to open rather than a fragment to paste into a template. |
Six of the nine describe how Markdown gets written, so they are hidden while HTML is being written; two describe the HTML, so they are hidden the other way round. Only GitHub Flavored Markdown sits in both, because it changes what each direction understands and not only what it emits.
Indented code is the one choice that costs something you cannot get back. A fence can name the language of the code inside it; four spaces of indentation is a block with nowhere to put that name. Convert <pre><code class="language-ts"> into an indented block and ts is gone from the result — which is why the control says so under its own label rather than leaving you to find it in a diff.
The defaults are what most projects expect to be handed: GitHub Flavored Markdown on, hash-prefixed headings, dashes for bullets, fenced code, underscores for emphasis, links beside their text, and inline HTML kept.
What this tool will not do
It reads the document, not the page. A browser runs a <script> and applies a <style>; neither one is text, so both are dropped along with <noscript>, <template> and everything in the document head — and whatever went is named above the result rather than thrown away in silence. Left alone, the underlying converter would have unwrapped them, which turns a page's JavaScript into a paragraph of prose.
It converts what you hand it and fetches nothing. Paste the markup rather than an address: no request leaves this page, which is the same reason nothing you paste leaves it either.
A whole document comes out unstyled and declares lang="en", because this tool knows the document's markup and not its language. Change that attribute and add your own stylesheet — the file is a starting point, not a finished page.
Where this gets used
Moving a published article into a repository, where the README and the docs are Markdown and the original was a web page. Paste the article body, take the Markdown, and the headings, lists, links and tables arrive with their structure intact.
Feeding a page to something that reads Markdown better than markup — a note-taking app, a static-site generator, or a language model, all of which do more with prose than with a document that is four fifths <div>.
And the other way, for the small jobs markup is still needed for: a description field that only accepts HTML, an email template, or a content management system whose editor has no Markdown mode.
Frequently asked questions
GitHub Flavored Markdown switch on. With it off there is no table syntax to write, and the converter falls back to the text of each cell.<script> is something a browser runs rather than something a reader reads, so unwrapping it would have turned your JavaScript into a paragraph. The same goes for <style>, <noscript> and <template>.Keep inline HTML on, anything Markdown cannot say survives as a tag. Going back is lossier by nature — Markdown carries no class names, no id attributes and no styling, so an element that had them arrives without them.