Markdown has become the default for READMEs, engineering blogs, meeting notes and release notes. The friction is in checking the result: you either commit and look at it on GitHub, or open a separate editor.
Type on the left and the rendered output appears on the right. GitHub Flavored Markdown — tables, fenced code, task lists — is supported, and the two panes scroll together so you never lose your place in a long document. Export the finished piece as an HTML file, print it to PDF, or copy the HTML source into another system.
How to use
- Write or paste markdown — Use the toolbar for bold, italic, headings, code, links, lists and tables. With text selected, a toolbar button wraps the selection instead of inserting a placeholder.
- Watch the preview — Scroll sync keeps the preview aligned with the editor. Switch to the HTML tab to inspect the generated markup directly.
- Export to PDF — Save PDF opens the print dialog with a layout tuned for print. Choose 'Save as PDF' as the destination for an A4 document in which code blocks and tables avoid breaking across pages.
- Save or copy HTML — Save HTML downloads a complete styled document; the copy button puts the same markup on your clipboard for pasting into an email or CMS. The raw
.mdfile can be downloaded separately.
Frequently asked questions
Why open the print dialog instead of downloading a PDF directly?
So that every language renders correctly.
Generating a PDF in JavaScript requires embedding a font, and a font covering Korean, Japanese and Chinese glyphs runs to several megabytes. The browser's print pipeline uses fonts already installed on the system and produces a vector PDF, so any script renders sharply at no download cost and the text stays selectable and searchable. One extra click buys a distinctly better file.
The output differs slightly from GitHub.
Markdown has several dialects, and GitHub layers its own extensions on top of GFM.
This renderer follows the GFM specification, so tables, strikethrough, task lists and autolinks behave identically. What GitHub adds server-side — alert blocks (> [!NOTE]), issue and PR autolinks (#123), @mentions and emoji shortcodes (:tada:) — stays as plain text here.
Can I write raw HTML inside the markdown?
Yes, inline HTML is rendered.
The output is sanitised with DOMPurify first, so <script> tags and event handler attributes like onclick are stripped — this prevents scripts from running when you preview markdown that came from someone else. Ordinary tags such as <details>, <img> and <table> work as expected.
Concepts worth knowing
CommonMark and GFM
Markdown launched in 2004 without a rigorous specification, so implementations disagreed. CommonMark is the standardisation effort that pins down the ambiguous cases, including nested lists and emphasis parsing.
GFM (GitHub Flavored Markdown) extends CommonMark with tables, strikethrough, task lists and autolinks. Most tooling now targets GFM, so staying inside it means your document looks roughly the same wherever you paste it.
Rendering markdown safely
Converting markdown to HTML introduces XSS risk, because markdown permits raw HTML — an input like <img src=x onerror=alert(1)> would otherwise execute.
Any service that renders user-supplied markdown must sanitise. This tool runs marked and then strips dangerous tags and attributes with DOMPurify before painting. If you render on the server, use isomorphic-dompurify or Python's bleach to do the same.
Print CSS fundamentals
Printing screen styles directly produces bad margins and elements sliced at page boundaries. Start with @page { size: A4; margin: 18mm 16mm; } to define paper and margins.
page-break-inside: avoid on code blocks and tables stops them splitting, and orphans and widows prevent a single stranded line at a page break. Hide screen-only chrome — navigation, buttons — inside @media print with display: none.