Markdown preview in both flavours

Almost always because the delimiter row does not have the same number of cells as the header row — GitHub flavour treats a mismatch as an ordinary paragraph rather than guessing, so three headers over two dashes rows gives you a line of pipes. The other four causes, in the order they come up: no delimiter row at all under the header; an unescaped pipe inside a cell, which needs to be written as a backslash followed by a pipe; a table indented four spaces, which makes it a code block; and CommonMark selected here, which has no tables in it whatsoever. Extra cells past the header count are dropped and missing ones are filled with blanks, so a ragged table renders but loses the overflow.

GitHub flavour is CommonMark plus five extensions: tables, task list checkboxes, strikethrough with tildes, autolinked bare URLs, and a filter on dangerous raw HTML. Everything else — headings, emphasis, lists, links, code fences, blockquotes — behaves identically, because the GFM spec is written as a diff against CommonMark 0.29 rather than as a separate language. Switch the toggle on this page and the difference is visible: a pipe table collapses into a paragraph, checkboxes turn back into square brackets, ~~text~~ keeps its tildes and footnote markers become literal text.

Because a single newline inside a paragraph is whitespace in every Markdown spec, and the paragraph reflows. GitHub confuses this by breaking on newlines inside issue, pull-request and comment boxes while keeping the standard behaviour for .md files in a repository — the same text renders two ways on one site. Tick “Treat every newline as a line break” to see the comment-box version. To force a break in a file that has to work everywhere, end the line with two spaces or a backslash.

By design: this preview escapes every character that arrives in the box, so a script tag, an iframe or an inline style shows as the characters someone typed instead of running. The counter under the document tells you how many tags were treated that way. A repository host takes a different route — GitHub allows a filtered subset of HTML and strips the rest — so a details/summary block or an align attribute will work there even though it stays visible here.

For the specified language, yes: the same block and inline rules, the same table and task-list extensions, the same anchor ids on headings, plus footnotes. What it does not reproduce is the layer GitHub adds on top of Markdown — Mermaid diagrams inside a fenced block, LaTeX between dollar signs, :emoji: shortcodes, alert blockquotes such as a NOTE or WARNING callout, and #123 or @user references that only mean something inside a repository. Those all show as plain text here, which is worth remembering before concluding that a document is broken.

Two megabytes per document, which is far more than any README and enough for a full changelog. Rendering a 250 KB document takes about 22 ms and a 2 MB one about 180 ms, so even the extremes redraw between keystrokes. Past 2 MB the page stops rendering rather than freezing the tab and asks you to check the document in halves.

Because anchor ids have to be unique, so the second one gets a numeric suffix — two sections called “Options” become #options and #options-1, exactly as they would in a repository. The id itself is built the same way: lowercase the text, drop punctuation, turn spaces into hyphens, keep letters outside ASCII. That is why a heading like “Step 1: install” links as #step-1-install, with the colon gone rather than encoded.