Logo

MonoCalc

/

Markdown to HTML

Programming

Pipe tables, ~~strikethrough~~, task lists and bare-URL autolinking on top of CommonMark.

Ctrl/Cmd+Enter converts · Ctrl/Cmd+K copies

Enter some Markdown to convert.

untitled.md

HTML fragment

Type or paste Markdown to get started
Load the sample above, drop a README onto the editor, or start typing - the HTML appears as you go.

Runs entirely in your browser - your Markdown is never uploaded, and the preview is a sandboxed frame with scripting disabled. Files up to 2 MB.

Sanitizer on · GitHub Flavored Markdown · indent 2

About This Tool

Markdown to HTML – convert README, docs and notes into clean markup

Markdown is how most technical writing starts life: README files, static-site posts, wiki pages, changelogs, issue templates and CMS drafts. The web, however, renders HTML. This Markdown to HTML converter bridges that gap in your browser, turning Markdown source into standards-compliant markup while showing a live rendered preview beside it, so you can check the structure and the appearance at the same time.

What the converter produces

By default you get an HTML fragment — body-level markup with no <html>, <head> or <body> wrapper — which is what you want when pasting into an existing page, a CMS field or a React template. Turn on Full HTML document and the same content is wrapped in a complete HTML5 document with a doctype, <meta charset="utf-8">, a responsive viewport tag, your title and an optional readable stylesheet, ready to save as a .html file and open directly.

CommonMark versus GitHub Flavored Markdown

CommonMark is the reference specification: headings, emphasis, lists, links, images, blockquotes, code and horizontal rules. GitHub Flavored Markdown (GFM) adds four widely used extensions on top — pipe tables, ~~strikethrough~~, task-list checkboxes and autolinking of bare URLs. Switching flavors is the fastest way to answer the question "why is my table not rendering?": under strict CommonMark a pipe table stays a paragraph full of pipe characters, because tables were never part of the specification.

Heading IDs, anchors and a table of contents

Every heading can be given a GitHub-style slug id — lower-cased, punctuation removed, spaces turned into hyphens, with repeats disambiguated as intro, intro-1, intro-2. Those ids are what deep links such as #installation point at, and they are what the optional table of contents is built from. The generated TOC is a nested <ul> of anchor links, limited to whatever heading depth you choose, and the nesting is normalised so a document that jumps straight from an H2 to an H4 still produces valid list markup.

Sanitizing untrusted Markdown

Markdown allows raw HTML, which means Markdown from a comment box, a form or a third-party repository can carry a <script> tag. Two independent switches control this. Allow raw HTML decides whether HTML written in the source is emitted as markup or escaped into literal text. Sanitize HTML decides whether whatever is emitted gets filtered — and it filters on an allowlist, so only known-safe elements and attributes survive, on* event handlers are stripped, and href and src values are checked against a scheme allowlist after character references are decoded.

Escaping and sanitizing are not the same job
Escaping turns <script> into visible text. Sanitizing removes it from the document. Leaving raw HTML on with sanitizing off publishes whatever the author wrote — only do that with content you trust, and pair it with a Content Security Policy on the page that serves the result.

Readable output you can hand to a reviewer

Generated HTML is normally one dense line. Pretty-print indents it at the width you choose, but only where indenting is meaningless to a browser: whitespace between two block elements is not painted, so it can be added freely, while a space between two inline elements is painted and is left exactly as it was. Anything inside <pre> is copied through byte for byte. The indented output is then re-parsed and compared against the compact output of the same document, and if they ever disagree the compact version is returned with a warning rather than shipping markup that changed meaning.

What the statistics tell you

Alongside the markup you get a word, line and character count for the source, the character and byte size of the output, a tally of every generated element, the document outline with each heading's level and slug, and an inventory of every link and image with an internal or external badge. That inventory is the quickest way to spot a http:// URL in a page that must be HTTPS-only, or a relative image path that will break once the HTML is pasted somewhere else.

Nothing leaves your browser
Parsing, sanitizing and rendering all happen in your tab, and the preview is a sandboxed frame with scripting disabled. That matters for release notes, internal runbooks and unreleased documentation, which routinely carry names and URLs that should not be uploaded anywhere.

Typical workflows

Paste a README to embed it in a marketing page. Convert a Markdown draft into an HTML email body and copy it as rich text straight into your mail client. Generate a standalone document for an offline handover. Drop a folder of docs in at once and export every converted file as a ZIP. Or simply type a snippet and read the markup, which is still the fastest way to learn precisely what a nested list, a fenced code block or a reference link compiles to.

Frequently Asked Questions

Is the Markdown to HTML free?

Yes, Markdown to HTML is totally free :)

Can I use the Markdown to HTML offline?

Yes, you can install the webapp as PWA.

Is it safe to use Markdown to HTML?

Yes, any data related to Markdown to HTML only stored in your browser (if storage required). You can simply clear browser cache to clear all the stored data. We do not store any data on server.

How does this Markdown to HTML converter work?

Your Markdown is parsed in your own browser by `marked`, a maintained CommonMark parser with GitHub Flavored Markdown built in, and the HTML it produces is then read into a node tree. Everything the tool adds on top - heading slug ids, the table of contents, the code-block class prefix, link targets, smart typography, sanitizing and indentation - runs as passes over that tree rather than as search-and-replace over the HTML text, so a `<` inside a fenced code block is never mistaken for a tag.

What is the difference between CommonMark and GitHub Flavored Markdown here?

CommonMark is the reference specification: headings, emphasis, lists, links, images, blockquotes, code and horizontal rules. GitHub Flavored Markdown adds four things this tool switches on with the flavor control - pipe tables, `~~strikethrough~~`, task-list checkboxes and autolinking of bare URLs. Switch to CommonMark and a pipe table stays a paragraph full of pipe characters, which is exactly what a strict parser does with it, and is the quickest way to find out why a table is not rendering on some other site.

Is the sanitized output safe to publish?

Sanitizing works as an allowlist rather than a blocklist: only known-safe elements and attributes survive, `<script>`, `<style>`, `<iframe>`, `<object>`, `<svg>` and friends are dropped with their contents, every `on*` handler is removed, and `href`/`src` values are checked against a scheme allowlist after character references are decoded - a URL carrying a reference the tool cannot decode is rejected rather than guessed at. Inline `style` attributes are removed too. It is a strong default, but no sanitizer is a substitute for a Content Security Policy on the page that ends up serving the HTML.

Does the rendered preview run the HTML?

No. The preview is a fully sandboxed iframe with scripting disabled, so nothing in your document can run, read the page around it, or navigate anywhere - that holds whether sanitizing is on or off. Images and other remote resources referenced by your Markdown are still fetched by the browser so the preview looks right, so a document full of tracking pixels will still make those requests.

Can indentation change what the HTML means?

It is not allowed to, and the tool checks rather than promises. Whitespace between two block elements is not painted, but a space between two inline elements is, and everything inside `<pre>` is byte-significant - so indentation is only ever added between block-level children, and the contents of a code block are copied through untouched. The indented output is then re-parsed and compared with the un-indented output of the same document; if they ever disagree the compact version is returned instead, with a warning.

Is there a size limit, and does anything leave my machine?

Nothing is uploaded - parsing, sanitizing and rendering all happen in your tab, which matters because README drafts and internal docs routinely contain unreleased names and internal URLs. Documents up to 1,000,000 characters convert, and files up to 2 MB can be loaded from disk; above roughly 40,000 characters the live conversion stops running on every keystroke and you convert on demand instead so typing stays smooth.