Markdown to HTML Converter — Live Preview & Safe HTML Export

What a Markdown to HTML converter has to get right

Converting Markdown to HTML sounds like a solved problem — until the document is real. A real document has a YAML front-matter block from a static site generator, a footnote added by a colleague, a GitHub alert callout, a table with alignment, a code block whose contents include the characters <div>, and — if it came from a public repo or a pasted snippet — possibly a piece of raw HTML you did not write and should not trust. A converter that only handles the happy path turns the front matter into a horizontal rule and a blob of text, drops the footnote silently, and either executes the raw HTML in your browser or mangles it without telling you. This tool was built around the unglamorous parts: a standards-based parser (the marked engine, bundled with the page rather than loaded from a CDN), a real sanitiser with a visible report, and an export pipeline where the preview, the printed page and the downloaded file are the same document wearing the same theme.

The output itself is deliberately boring, which is the point: headings become h1–h6 with stable anchor ids, pipe tables become table with thead and tbody, task lists become real disabled checkboxes, and there are no wrapper divs, inline styles or tracking artefacts to clean up afterwards. Copy the fragment into a CMS, a GitHub Pages site or an email template and it takes on the destination's own styling.

Convert a document in four steps

1. Bring the Markdown in. Type it, paste it, drop a .md file onto the editor (up to 2 MB), or start from the built-in sample that exercises every feature. 2. Set the dialect. GitHub Flavored Markdown on or off, single-line breaks on or off, and how raw HTML and YAML front matter should be treated. 3. Check it like a reader. Split view with scroll-synced panes, the safety strip above the preview, the outline for long documents, and the theme you intend to ship. 4. Take it out the way you need it. Copy the clean HTML fragment, copy formatted text for Word or Google Docs, copy a complete standalone page, download the .html file, or print it to PDF — all from the same conversion, so the formats can never disagree with each other.

The safety model: sanitised means counted, not just claimed

Markdown allows raw HTML, and raw HTML can carry <script> tags, onerror-style event handlers and javascript: links — including disguised ones with encoded characters or tabs inside the scheme, which the checker here decodes before judging. In the default Sanitise mode every document is rebuilt against an allowlist: known-safe elements and attributes survive, everything else is removed and counted, and the strip above the preview shows the count — “removed: 1 script · 2 event handlers · 1 unsafe URL”. Nothing is silently executed and nothing is silently dropped. Two other modes exist for specialists: Escape shows embedded HTML as literal text (the right choice for documentation about HTML), and Allow passes raw HTML through untouched for documents you wrote and fully trust — it is labelled unsafe in the interface, because it is. Your own generated markup is safe by construction in every mode: link schemes are checked even for links written as Markdown.

Supported syntax — and the honest limits

Supported: CommonMark plus GitHub Flavored Markdown — headings with anchors, emphasis, strikethrough, links and images, fenced and indented code, pipe tables with alignment, task lists, nested lists, blockquotes, autolinks — plus footnotes with backlinks, GitHub alert callouts ([!NOTE], [!TIP], [!IMPORTANT], [!WARNING], [!CAUTION]) and YAML front matter. Not rendered: LaTeX mathematics and Mermaid diagrams are not drawn in the preview — they need two heavy rendering libraries to serve two niche syntaxes. Your ```mermaid and ```math blocks stay intact in the exported HTML with their language classes, so a downstream renderer (or GitHub itself) can still draw them; this page simply will not pretend to. It is also a single-document tool: for converting a whole folder of files, a command-line tool like Pandoc or a static site generator is the right instrument, and for keeping documents in sync across devices you want an editor with cloud storage — this page deliberately has no accounts, no uploads and no sync.

Writing in Markdown, publishing everywhere else

The documents people convert are remarkably consistent: README files that need to become documentation pages, blog drafts written in a text editor and pasted into a CMS, release notes, course material, email newsletters and the Markdown that large language models produce when you ask them for structured writing. In every case the workflow is the same — write where it is comfortable, publish where it is required — and the failure modes are the same too: a table that arrives unstyled, a footnote that vanishes, a heading structure that breaks the page it lands in. That is why the theme system matters as much as the parser: choose the exported theme to match the destination and the document arrives already dressed. When the job is the reverse — an HTML page that needs to become Markdown — or when the Markdown is really a counting and editing task, the word counter and the JSON formatter cover the neighbouring ground; this page's one job is the Markdown-to-HTML hop, done carefully.