KeroTools

Markdown to HTML With Live Preview

Convert Markdown to clean HTML with a live preview that updates as you type.

Input
0 chars
HTML

Your document stays on your device

Nothing to delete afterwards

Safe for internal documentation

Works in every modern browser

How it works

  1. 1

    Paste your Markdown

    A README, a documentation page, a post, or notes you want as HTML.

  2. 2

    Check the preview

    Confirm the structure came out as intended before you look at the markup.

  3. 3

    Copy the HTML

    Take it into a CMS, an email template, a static site, or a documentation page.

Why use this tool

CommonMark plus GitHub extensions

Tables, strikethrough, task lists, and autolinks — the dialect most Markdown is actually written in.

Preview and markup together

See the rendered result and the HTML it produced, so you can check both before pasting either.

Semantic output

Real headings, lists, and tables rather than a wall of styled divs, so the markup means something.

Line-break behaviour you can choose

Decide whether a single newline becomes a break or joins the paragraph — the setting people always want.

Nothing is uploaded

The conversion happens in your browser — unpublished documentation never reaches a server.

Free, no account

No signup, no watermark, no cap on how much you convert.

There is no such thing as Markdown — there are several

This is the fact behind most of the surprises. The original 2004 description was a short document and a Perl script, with no formal grammar and no test suite, which left a great deal genuinely undefined. Implementations filled the gaps differently, so the same input produced different output depending on which one you used. CommonMark exists to fix exactly that: a precise specification with a conformance suite, and it is now what most serious parsers target. But CommonMark deliberately excludes things people use constantly, so GitHub Flavored Markdown adds tables, strikethrough, task lists, and automatic links on top. The practical consequence is that a document with a table renders as a table in GitHub and as literal pipe characters in a strict CommonMark parser. Before blaming your Markdown, check which dialect the destination speaks.

A single newline is not a line break

This is the behaviour that confuses more people than everything else combined, and it is not a bug. Markdown treats consecutive lines as one paragraph and joins them with a space, because the format was designed so that hard-wrapping a paragraph in a text editor would not change the output. Two lines of an address written on separate lines therefore come out on one line. The classic remedy is two spaces at the end of a line, which is a genuinely awful convention because it is invisible and editors strip it. A backslash at the end of the line does the same thing in CommonMark and is at least visible. And a blank line starts a new paragraph, which is usually what people actually wanted. GitHub changed the default in comment fields so a newline is a break there, which is why the same text behaves differently in an issue and in a README.

Markdown lets HTML through on purpose, and that is a security decision

Raw HTML inside Markdown is a feature, not an oversight: the original design assumed you would drop into HTML whenever Markdown could not express what you needed. That means a Markdown-to-HTML converter is, by specification, allowed to pass a `<script>` tag straight through to its output. For your own documents that is exactly what you want. For anything a user submitted — a comment, a review, a profile bio, a support ticket — it is a stored cross-site scripting vulnerability waiting to happen, and the conversion step is where it gets built. The rule worth carrying is simple: rendering trusted Markdown is safe, rendering untrusted Markdown requires sanitising the resulting HTML afterwards against an allowlist of tags. Never rely on the Markdown parser itself to make user input safe, because it was not designed to.

What Markdown deliberately cannot do

Markdown is a formatting language for prose, not a layout language, and its limits are intentional rather than missing features. There is no syntax to put a class or an id on an element, no way to set an image width, no way to add an attribute of any kind. Table alignment is the one exception, and even that is limited to left, right, and centre. When you need any of it, the answer within Markdown is to write the HTML inline — which works, and immediately leaves the portable subset, because that fragment will not render in a context that strips HTML. This is the tradeoff at the heart of the format: it stays readable as plain text precisely because it refuses to grow. If you find yourself writing more HTML than Markdown, the document has outgrown the format.

Where the output goes changes what you should keep

The HTML that comes out is deliberately bare — headings, paragraphs, lists, and links, with no wrapper divs and no classes — because that is what inherits a stylesheet cleanly. For a page you control, that is exactly right. Email is the exception worth planning for, since most clients strip `<style>` blocks and ignore external stylesheets, so anything that must look designed in an inbox needs its CSS inlined per element after conversion. A CMS is the other case: many editors sanitise pasted HTML and quietly drop attributes, so paste into the source view rather than the visual one. And if the destination accepts Markdown directly — as most static site generators, wikis, and documentation platforms do — converting first is a step backwards, because you lose the source that was easier to edit.

Why converting locally matters for this kind of text

Consider what is usually in a Markdown editor. Internal documentation describing how a system works. A README for a repository that is not public yet. A blog post before publication. Meeting notes with names in them. A runbook that names hosts and describes what to do when something fails. Markdown is the format people write internal knowledge in, which makes a pasted document a description of how an organisation operates — rarely secret in the dramatic sense, and rarely something you would choose to hand to a stranger either. A hosted converter receives all of it. This tool converts in the page and transmits nothing, which you can confirm in the Network tab of your developer tools.

Common mistakes to avoid

  • Expecting a single newline to break the line. Markdown joins consecutive lines into one paragraph by design — use a blank line for a new paragraph, or a backslash at the end for a hard break.
  • Rendering user-submitted Markdown without sanitising the output. Raw HTML passes through by specification, so a `<script>` tag in a comment becomes a stored cross-site scripting problem at the conversion step.
  • Assuming every parser speaks the same dialect. Tables, task lists, and strikethrough are GitHub extensions, not CommonMark, so a table can render as literal pipe characters elsewhere.
  • Reaching for inline HTML to set a class or an image width. It works and it leaves the portable subset — that fragment will vanish anywhere HTML is stripped.
  • Converting Markdown that the destination would have accepted directly. Static site generators, wikis, and documentation platforms usually take Markdown, and converting first loses the easier-to-edit source.

How it compares

AspectThis toolOnline convertersA static site generator
Content sent to a serverNeverUsually yesNo
GitHub extensions supportedYesVariesUsually
Output inherits your CSSYesVariesYes
Setup requiredNoneNoneInstall and configure
Account or signupNot neededOften requiredNot needed
PriceFreeFree / paid tiersFree

Features

Tables and task lists

The GitHub extensions that are not in strict CommonMark but are in most real Markdown.

Live preview

The rendered output updates as you type, so mistakes surface immediately.

Fenced code blocks

Triple-backtick blocks become `pre` and `code` with the language recorded as a class.

Clean, minimal markup

No wrapper divs, no generated class names, no inline styles — the HTML inherits your stylesheet.

Unicode throughout

Arabic, Turkish, and accented text passes through unchanged in both directions.

Handles long documents

Whole manuals convert without an upload or a size cap.

Nothing to install

No static site generator, no runtime, no dependencies — it runs on the web page.

Arabic and RTL ready

Full interface in eight languages, including right-to-left Arabic.

Secure by default

Served over HTTPS, with no content tracking and no third-party upload.

Who uses it

Technical writers

Getting documentation into a CMS that accepts HTML but not Markdown.

Developers

Checking how a README will render before pushing it to a repository.

Content editors

Turning a writer’s Markdown draft into markup a publishing system can take.

Newsletter writers

Producing the HTML body of an email from a draft written in plain Markdown.

Frequently Asked Questions

No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.

Yes — completely free, with no account and no limits.