Markdown Previewer

Markdown is designed to be readable before it is rendered, which is why it took over documentation, README files and half the writing tools on the internet. The catch is that the moment your document grows past a heading and two paragraphs, you need to see the rendered version to trust it — and a preview only helps if it looks like the finished page rather than a stack of undifferentiated text.

This previewer parses your source with a real CommonMark implementation plus GitHub's extensions, so tables have borders, task lists have checkboxes, footnotes land at the bottom and fenced code is highlighted by language. Headings get the same anchor slugs GitHub generates, which means an in-document link written today still works when the file is pushed to a repository.

The editing side is a plain text area with the parts that were missing bolted on properly. A formatting toolbar covers bold, italic, strikethrough, inline code, links, images, three heading levels, quotes, all three list types, tables and rules — and every one of them toggles, so pressing bold on bold text takes the asterisks off again. Ctrl+B, Ctrl+I and Ctrl+K do what they do everywhere else. Tab indents a nested list item and Shift+Tab pulls it back out. Pressing Enter inside a list starts the next item and renumbers as it goes, and pressing it on an empty item ends the list instead of adding another bullet to nowhere.

Two panels sit under the workspace. The outline lists every heading with its level and line number and jumps both panes to it. The check reads the document for the mistakes that actually change what a reader sees — a list glued to the paragraph above it, a table row that has fewer cells than its header, a fence nobody closed, a heading missing the space after its hash — and reports each one with a line number you can click.

Four things can go on the clipboard, because four different destinations want four different things. The Markdown itself, for pasting back into a repository or a CMS that speaks Markdown. The HTML fragment, for a template that already has a page around it. A complete HTML page with the stylesheet inlined, which opens correctly anywhere with no other files. And rich text, which is the one people ask for most: the formatted document lands in a word processor, a slide, or an email body with its headings, lists and tables intact rather than as a wall of asterisks.

Downloads cover .md and the standalone .html, and printing is how you get a PDF. Going through the browser's own print dialogue produces a PDF with selectable text and real page breaks, which a screenshot-based export cannot — code blocks, quotes and tables are told not to split across pages, and headings are kept with the text beneath them.

All of it comes from the same rendered document, whichever view mode you are in. That sounds obvious and is worth stating: an export that quietly reads whatever happens to be on screen produces an empty file when the preview is hidden, which is exactly the kind of failure you only notice after sending someone the file.

When Markdown does something you did not intend, the cause is almost always a blank line, an indent, or a space that is missing or in the wrong place — and none of those are visible while you type. That is why the check exists and why it reports line numbers rather than general advice.

The three that catch people repeatedly: a list needs a blank line above it, or it is absorbed into the preceding paragraph and renders as one run-on line. Nested list items must be indented to line up with the parent item's text, not its bullet, or the nesting silently flattens. And indenting a line by four spaces creates a code block, which is why a list nested one level too deep sometimes appears in a grey box instead.

The hard line break is the worst offender because it is made of two trailing spaces — invisible characters that most editors delete when they save. If a line break inside a paragraph keeps disappearing, that is why; a trailing backslash does the same job and survives being saved. The check flags trailing-space breaks for exactly this reason.

The original 2004 implementation left a lot undefined, and different renderers filled the gaps differently — which is how the same file came to produce three different pages in three different places. CommonMark exists to specify the ambiguous cases precisely, and GitHub Flavored Markdown adds tables, task lists, strikethrough, footnotes and autolinking on top of it. This preview is CommonMark plus those extensions, which is the combination a README, a docs site or a static-site generator will most likely apply to your file.

Raw HTML is the deliberate exception. Markdown permits it and GitHub renders it, but this preview shows it as literal text and never executes it — so a document pasted from anywhere cannot do anything to the browser previewing it. The check lists every raw tag it finds so the difference is never a surprise: a <details> block will collapse on GitHub and appear as text here. If a document has to work in several places, staying inside the CommonMark core is the portable choice, and a fenced code block with a language hint beats an indented one for the same reason.

Front matter gets the same explicit treatment. The block of YAML between two lines of dashes at the top of a file is metadata for a site generator, not content, so it is kept out of the rendered body and shown separately instead of appearing as a stray rule followed by a paragraph of key-value pairs.