Skip to content
Markdown toolkit

Markdown / HTML converter

Bidirectional conversion between Markdown and HTML. GFM (GitHub Flavored Markdown) parser: heading, bold, italic, strikethrough, inline and fenced code with language hint, ordered and unordered lists, blockquote, links, images, pipe-syntax tables with alignment. Live rendered HTML preview alongside the copyable text-area output, with one-click direction swap to round-trip your content.

Live preview

How to use the converter

  1. 1

    Pick a direction

    Markdown -> HTML to render your.md to HTML ready to paste into a CMS or blog. HTML -> Markdown to extract content from an HTML page and strip away inline styles, classes, and superfluous tags.

  2. 2

    Paste the source

    Live preview is always on: every input is converted automatically with 300ms debounce. No 'Convert' click required, but the button is still available to force a rerender.

  3. 3

    Inspect the output

    Three panels: input (left), text output (right), HTML live preview (below). The preview shows how the HTML renders in your browser. The output text is the string ready to copy.

  4. 4

    Swap the direction

    'Swap direction' button: moves the last conversion's output into the input and flips the direction. Useful for MD -> HTML -> MD round-trip to check that the content is normalized.

Parser scope and limits

GFM subset, not full CommonMark. The parser implements the syntax most used in practice: heading 1-6, bold, italic, strikethrough, inline and fenced code with language hint for external syntax highlighting (Prism, highlight.js), ordered and unordered lists, blockquote, links, images, pipe-syntax tables with alignment, HR. It does not support footnotes, task lists, definition lists, math LaTeX, iframe embeds, GitHub-style autolinks (#123, @user). For strict CommonMark spec compliance you need a dedicated server-side parser.

HTML -> Markdown reverse. The reverse conversion walks the DOM tree via the browser's native DOMParser and produces equivalent Markdown for headings, paragraphs, bold, italic, code, links, images, blockquote, lists and tables. All inline styles, CSS classes, container divs and semantically empty spans are ignored: the semantic content is extracted and the presentation chrome dropped. The behavior is intentional for content portability. It does not handle complex nested HTML, iframe, script, form.

Operational privacy. Parsing is entirely local to the browser: the content of a draft post, internal documentation or personal notes does not transit through third-party backends. Useful in contexts where the content itself has value (NDA material, enterprise documentation, pre-publication assets).

Supported Markdown syntax

Heading
# H1... ###### H6 (atx-style, hash + space). Setext-style (===== below the title) is not supported.
Bold / italic / strike
**bold** or __bold__, *italic* or _italic_, ~~strike~~. Nested combinations (***bold italic***) partially supported.
Inline and fenced code
Inline: `code`. Fenced block: ```lang + newline + code + newline + ```. The language hint becomes class="language-xxx" for external highlighters such as Prism or highlight.js.
Lists
Unordered: - item, * item, + item. Ordered: 1. item (any number, the renderer renumbers). Nested lists: 2-space indent NOT supported in this subset (deliberate limitation, would reduce parse robustness).
Blockquote
> text. Consecutive multiline are grouped. No nested blockquote in this subset.
Links and images
Link: [text](url). Image: ![alt](url). Reference-style ([text][ref]) is not supported.
GFM tables
Pipe-syntax with separator row |---|---|---|. Alignment via :-- (left, default), :-: (center), --: (right) on the separator row.
HR
---, ***, ___ on a standalone line.

Glossary

Technical terms used on this page, briefly explained.

Markdown #
Plain-text syntax for formatted text, created by John Gruber in 2004. Converted to HTML by a parser. De facto standard for GitHub READMEs, technical documentation, blog posts.
GFM #
GitHub Flavored Markdown, an extension of Markdown with tables, task lists, fenced code blocks, autolink. Natively supported by GitHub, GitLab, many modern CMSes.
CommonMark #
Formal Markdown specification (commonmark.org), 2014, aims to resolve ambiguities in the original syntax. Implementations: cmark, markdown-it, commonmark.js.
Fenced code block #
Code block delimited by triple backticks (```) or triple tildes (~~~), optionally with a language hint for syntax highlighting. Alternative to indent-4-spaces code blocks (not supported here).
Inline parser #
Markdown parser component that processes inline syntax (bold, italic, code, link, image) inside a previously identified block. Distinct from the block parser that identifies heading, list, blockquote.
DOM walker #
Technique for traversing an HTML tree via the browser's native DOM API (DOMParser, childNodes, tagName). Used here for HTML -> Markdown reverse: recursive walk, dispatch by tagName, output Markdown string.

Frequently asked questions

Does Markdown -> HTML produce exactly the same HTML as GitHub?
No. GitHub uses cmark-gfm + a custom sanitizer. This parser is a GFM subset and does not implement: footnotes, task lists - [ ], issue/PR autolink (#123), @user mentions, emoji shortcodes :tada:. For exact GitHub-compatible rendering use cmark-gfm server-side.
Does HTML -> Markdown lose information?
Yes, deliberately. All inline styles, CSS classes, container divs, semantically empty spans are ignored. The converter extracts the semantic content (heading, paragraphs, bold, italic, code, links, images, lists, tables) and discards the presentation chrome. This is the desired behavior for content portability.
Can I use inline HTML inside Markdown?
Partially. Standard Markdown allows inline HTML, but this parser HTML-escapes every character in the input before applying the rules. So <span>hello</span> in input becomes literal text, not a rendered span. For preserved inline HTML use a commonmark-spec compliant parser.
Do GFM tables with multiline cells work?
No. The parser assumes one row per line. If a cell contains <br> or a newline, the row breaks. Workaround: keep table rows on a single line, or convert the table to manual HTML before pasting.
Why no live preview with dual-pane scroll sync?
Deliberately limited scope. The live preview here is always full-output, no scroll-sync. For dual-pane editors with sync there are StackEdit, Typora, Obsidian; this is a one-shot converter, not an editor.
Does MD -> HTML -> MD round-trip produce the same file?
Typically no, but the semantic content is preserved. Common differences: normalized whitespace/newlines, attribute order on tags, table columns with identical width for alignment (lost in reverse). For 'clean' Markdown files (no inline HTML, no edge cases), the round-trip should be idempotent on the second pass.
Can I process large.md files (1MB+)?
Technically yes, but the parser is synchronous and single-pass line-by-line. For very large files (10MB+) the browser may freeze for a few seconds. For serious batch processing use a server-side parser (Pandoc, marked CLI).

Who builds these tools?

Maurizio Fonte, senior IT consultant with 20+ years in PHP, Laravel, unmanaged Linux infrastructure, applied cybersecurity and AI/LLM integration. Production backends, legacy code modernization, security audits, custom AI agents and MCP servers: the work behind every tool published here.

About Maurizio Fonte