Markdown preview: paste your markdown and see exactly how it renders

You have a README, a changelog, a pull request description or a documentation page written in markdown, and you want to see the rendered result before you commit it. This is a split-pane editor: raw markdown on the left, live rendered output on the right, updating as you type. No account, no upload, no round trip — the parser runs in your browser and your text stays in the tab.

Paste into the left pane, or use the Upload button to load a local .md or .markdown file. The upload is read with the browser’s own file reader and never leaves your machine; that is the honest answer to the usual first question. Your content is auto-saved to the browser’s local storage two seconds after you stop typing, so a reload does not lose your work — and equally, it means the text persists on that device until you clear it, which is worth knowing on a shared machine. The Clear button removes both the editor content and the saved copy.

Which flavour of markdown this renders

This matters more than people expect, because “markdown” is not one language. The preview parses CommonMark plus GitHub Flavored Markdown, using the same parser family that renders markdown across a great deal of the JavaScript ecosystem. Concretely, that means the GFM extensions on top of CommonMark are all live:

What is not here, stated plainly so you do not chase a bug that is really a missing extension: there is no LaTeX or KaTeX math rendering, so $x^2$ stays literal text. There is no emoji shortcode expansion, so :smile: renders as those exact characters — but pasted Unicode emoji work fine, because they are just characters. There is no diagram rendering, so a ```mermaid block is treated as a code block and highlighted rather than drawn. And YAML front matter is not stripped: a --- fence at the top of the file is read as ordinary markdown, which typically renders as a horizontal rule followed by a heading rather than disappearing the way a static site generator would hide it. Delete the front matter before pasting if it gets in the way.

Where markdown flavours genuinely differ

Most “it looked different on GitHub” reports come down to three specific behaviours.

Line breaks. This is the big one. In CommonMark and in GFM as specified, a single newline inside a paragraph is not a line break — consecutive lines are joined into one flowing paragraph. To force a break you end the line with two trailing spaces, or use a <br> tag. GitHub’s comment boxes, issues and pull request descriptions turn on a non-standard “hard break” mode where every newline becomes a break, and so do Slack-adjacent editors and many note apps. This preview follows the specification, not the comment-box convention. So if your text renders as one long paragraph here but as separate lines in a GitHub issue, neither is broken — you are comparing a spec-compliant renderer against a hard-break one. README files on GitHub are rendered without hard breaks, which is why this preview matches a README more closely than it matches a comment.

Nested lists. Indentation rules are the second most common surprise. CommonMark ties a nested item’s indentation to the width of its parent’s marker, so a child under - item needs two spaces while a child under 1. item needs three. Editors that insert a hard tab, or four spaces regardless, can push a list item far enough that it becomes an indented code block instead of a sub-item. If a nested bullet renders in a grey monospace box, that is what happened: reduce the indentation. Similarly, a blank line between list items switches the list from “tight” to “loose”, which wraps every item in a paragraph and visibly increases the spacing — correct behaviour, not a styling bug.

HTML passthrough. Raw HTML is rendered here rather than escaped, which is what GitHub does for a controlled subset. That makes <details><summary> collapsibles, <kbd> keys and inline <img> tags work as written. Two things follow from it. First, markdown syntax inside an HTML block is generally not reprocessed, so **bold** on the line directly after an opening <div> may come out literal — leave a blank line to get markdown parsing back. Second, this preview does not run raw HTML through a sanitiser, so it will render whatever markup you give it. For your own drafts that is exactly what you want; do not use it as a safety check on markdown from an untrusted source, and be aware that GitHub and most content platforms strip far more than this does, so “it worked in the preview” is not a guarantee it survives publishing.

Working in the editor

The formatting toolbar inserts syntax around your selection or at the cursor: bold, italic, heading, link, image, fenced code block, inline code, unordered list, ordered list, task list, blockquote, horizontal rule and a table skeleton. Four keyboard shortcuts cover the ones you reach for constantly:

A view toggle switches between split, editor-only and preview-only. Split is the default on a desktop-width screen; on a narrow screen the two panes become tabs, because a split pane at phone width is unusable. A cheat sheet button (shown on wider screens) lists the syntax for headings, emphasis, strikethrough, inline code, both list types, task lists, links, fenced code blocks, blockquotes, rules and tables, so you do not have to leave the page to look up a table divider.

Code blocks are syntax-highlighted with a dark theme. Tag the fence with a language — ```javascript, ```python, ```bash — and the keywords colour correctly; leave it untagged and you get a plain monospace block, which is often the right choice for log output or plain text. Tables render inside their own horizontally scrolling container, so a wide table scrolls rather than breaking the page layout. Task list checkboxes are rendered as genuine, disabled checkboxes: they show state accurately and cannot be clicked, since the markdown source is the record and toggling a box in the preview would put the two out of sync.

The status bar

Along the bottom you get a live count of words, characters, characters excluding whitespace, and lines, plus an estimated reading time. The reading-time figure divides the word count by 200 words per minute and rounds up, with a floor of one minute — a conventional assumption, not a measurement of you. The counts are taken from the markdown source, so syntax characters such as ** and # are included in the character total; expect the number to run slightly above what the rendered prose would count.

Getting your work back out

• Copy puts the raw markdown source on your clipboard.
• Download saves it as document.md.
• To keep the rendered output, select inside the preview pane and copy — pasting into a rich-text editor generally preserves the formatting, since you are copying real rendered HTML.
• To print or make a PDF, switch to preview-only first so you export the rendered document rather than a half-page of source.

Things that commonly go wrong

• Everything after a certain point is bold or italic. An unclosed ** or *. The live preview makes this obvious the moment it happens, which is most of the reason to preview at all.
• A code fence swallowed the rest of the document. An opening ``` with no closing fence. Count your fences — they must pair.
• A table renders as plain text. The divider row is missing or malformed. Every table needs a second row of dashes with a cell for each column, and the pipe count must match the header. If you are building a table from scratch rather than fixing one, the site’s markdown-table-generator produces the aligned source for you.
• Underscores inside a filename or variable turned into italics. Wrap identifiers in backticks, or escape the underscore as \_.
• A heading did not render. A # needs a space after it, and the line must start at the left margin — leading spaces can turn it into something else entirely.
• A numbered list restarted or renumbered itself. Markdown takes the first number as the start and renumbers the rest sequentially; writing 1. on every line is legal and produces 1, 2, 3.

Because the preview and the platform you publish to may not run identical renderers, treat this as an accurate check of your markdown — is the syntax well-formed, do the tables and lists and fences parse the way you intended — rather than a pixel-exact simulation of any one destination. For structural correctness, which is what actually breaks, it is exactly the right check.