Markdown to HTML

How to use this Markdown converter

1. Type or paste Markdown into the left box.
2. See a live rendered preview, and the raw HTML below.
3. Copy the HTML to paste into your site or email.

Which Markdown syntax is supported?

Headers (#), bold and italic, links, inline code and code blocks, blockquotes, ordered and unordered lists, and horizontal rules — the core CommonMark features used in most READMEs and docs.

Why CommonMark had to exist — Markdown's original ambiguity problem

Markdown's original 2004 specification, while genuinely revolutionary for its time, was actually quite informal and left real, meaningful gaps in exactly how various specific edge cases should be handled — nested lists, mixing different emphasis markers, and several other genuinely common everyday situations. This led directly to dozens of different Markdown implementations across different platforms and tools, each interpreting those specific ambiguous edge cases somewhat differently from all the others, meaning identical Markdown source text could genuinely render as visibly different HTML output depending entirely on which particular parser happened to process it. CommonMark was created specifically to solve this exact interoperability problem — a rigorous, fully unambiguous specification with an accompanying, extensive official test suite, letting different implementations verify they actually produce identical, matching output for the exact same input. This tool implements the core CommonMark specification precisely for this reason, ensuring consistent, predictable, standardized behavior rather than one more slightly different, incompatible dialect among the many that existed before CommonMark's standardization effort.

Why raw HTML passthrough is both a genuine feature and a real security risk

The CommonMark specification deliberately allows raw HTML tags to be embedded directly within Markdown source and pass straight through completely unmodified into the final rendered output — this is an intentional, deliberate feature specifically letting Markdown authors reach for genuine HTML when Markdown's own simpler syntax can't achieve some specific formatting effect they need. But this exact same deliberate feature is precisely what makes the FAQ's warning above so genuinely important to take seriously: if the Markdown source text ever comes from an untrusted source (a user comment, an external content submission, or similar), that raw HTML passthrough becomes a direct, real, and genuinely serious cross-site scripting (XSS) vulnerability, since a malicious <script> tag embedded directly in supposedly "safe" Markdown text would pass straight through completely unmodified and then execute with full, unrestricted privileges once actually rendered on a live page. This is exactly why any Markdown renderer handling untrusted, externally submitted user content absolutely needs a separate, dedicated HTML sanitization step applied afterward — this tool, as its own FAQ correctly and explicitly states, converts Markdown syntax to HTML but deliberately does not perform that separate sanitization step itself.

GitHub Flavored Markdown — why these specific extensions became so widely popular

As the FAQ above notes, this tool implements core CommonMark rather than the extended GitHub Flavored Markdown (GFM) dialect specifically, and understanding the difference helps clarify exactly what's covered and what genuinely isn't. GFM adds several genuinely popular extensions on top of the core CommonMark specification — tables (using pipe characters to define columns), task lists (checkbox syntax rendering as actual interactive or visual checkboxes), strikethrough text, and automatic hyperlinking of bare URLs without requiring explicit link syntax. These specific extensions became so widely popular and commonly expected largely because of GitHub's own sheer massive scale and reach — README files, pull request descriptions, and issue comments across millions of individual repositories all use GFM specifically, which normalized these particular extensions as something many developers now simply, informally expect from "Markdown" generally, even though they were never actually part of the original core CommonMark specification this tool specifically implements.

Where Markdown-to-HTML conversion is genuinely useful beyond just README files

While READMEs are Markdown's most commonly recognized, visible use case, converting Markdown to HTML is genuinely useful across several other real, practical everyday contexts too. Static site generators (used for blogs, documentation sites, and personal portfolio sites) commonly let authors write content in Markdown specifically for its simplicity and readability, then automatically convert it to HTML at build time for actual publishing. Email marketing and transactional email tools frequently accept Markdown as a genuinely simpler, faster way to compose formatted email content without needing to hand-write actual raw HTML markup directly. And many note-taking and documentation applications use Markdown specifically as their own internal storage format, converting it to HTML only at the final moment of display or export. In every one of these specific contexts, the underlying appeal is exactly the same: Markdown is genuinely faster to write by hand than raw HTML, while still reliably converting into fully valid, correctly structured HTML whenever it's actually needed.

Limitations of this tool

As the FAQ above explains, this tool implements core CommonMark syntax — headers, emphasis, links, code blocks, blockquotes, lists, and horizontal rules — entirely within your browser, but doesn't currently support GitHub Flavored Markdown extensions like tables, task lists, or footnotes described in more detail above. And as the second FAQ item explicitly and importantly warns, this tool converts Markdown syntax to HTML but performs no sanitization of the output at all — if your specific Markdown source includes raw HTML or comes from any untrusted source, you must sanitize the resulting HTML output yourself before inserting it into a live page, to avoid the genuine XSS risk explained in more detail above.