Markdown Preview Online: Write and Render Markdown in Real Time

Markdown reads close enough to plain text that it's tempting to trust it by eye — but “close enough” is exactly where the mistakes hide. A table's pipe alignment can look tidy in a monospace editor and still render with a missing column, because the column count is set by the separator row, not by how the pipes line up visually. A nested list can look correctly indented and still flatten into one level, because Markdown's indentation rules for list nesting aren't the same as your editor's tab width. None of that is visible in the source. It's only visible once something actually parses the document and renders it, which is the entire reason a markdown preview online tool exists rather than people just reading source and trusting it.

The other reason to preview before committing: Markdown itself is small, but the flavor almost everyone actually writes — GitHub Flavored Markdown — is bigger. GFM extends the CommonMark base spec with tables, task lists (- [ ] / - [x]), strikethrough (~~text~~), and automatic autolinking of bare URLs. Those extensions aren't part of every Markdown parser, so a document that renders correctly on GitHub can render differently — or not at all — somewhere with a stricter, CommonMark-only renderer. Previewing with a GFM-aware converter is how you find out before a README ships with a table that silently degrades into a wall of pipe characters.

It helps to see the extensions side by side with what they render to, because the failure modes are usually in the details — an extra space, a missing blank line, a separator row with the wrong number of columns.

| Tool          | Category  | Client-side |
| ------------- | --------- | ------------ |
| JSON Formatter| json      | yes          |
| Markdown Preview | utilities | yes       |

- [x] Draft the README
- [x] Add a usage example
- [ ] Link the changelog

~~Deprecated in v2~~ — use `v3` instead.

See https://example.com/docs for the full reference.

Tool              Category   Client-side
----------------  ---------  ------------
JSON Formatter    json       yes
Markdown Preview  utilities  yes

☑ Draft the README
☑ Add a usage example
☐ Link the changelog

Deprecated in v2 (struck through) — use v3 instead.

See https://example.com/docs (rendered as a clickable link) for the full reference.

Every line in that source block is CommonMark-plus-GFM, and every one of those extensions is exactly the kind of thing a plain text editor gives you zero feedback on. You can write a broken separator row — three columns of headers over a separator with two — and a text editor will never tell you; a renderer will, immediately, because the columns won't line up.

Markdown allows raw HTML to pass through inline — it always has, since the original spec. That's convenient when you want an embed a Markdown syntax can't express, and it's a real cross-site scripting vector the moment the document being rendered came from somewhere you don't fully control and the rendered output gets shown to other people. A README pulled from a fork, a comment body stored and re-rendered for other users, a wiki page anyone can edit — render any of those with a converter that executes embedded <script>tags or event handler attributes, and you've built a stored-XSS pipeline, not a documentation viewer.

A converter that escapes raw HTML by default — showing <script>alert(1)</script>as literal, visible text instead of running it — isn't being conservative for no reason; it's making the one decision that keeps a markdown to html conversion safe to render for someone other than the person who wrote the source. That's the behavior worth checking for in any markdown editor online before you use it on content you didn't write yourself, and it's exactly how GenKitLab's Markdown Preview behaves: raw HTML is escaped, not executed, so a pasted document — however untrusted — cannot run anything in the page.

• Previewing a README before pushing it.GitHub's own renderer is the real target, and a GFM-aware preview catches the table and task-list mistakes that a plain-text read-through misses, before a badge or a code block ends up broken in the actual repo view.
• Drafting documentation locally. Writing a docs page in Markdown and checking headings, nested lists and links render the way you expect, without round-tripping through a static site generator just to see one paragraph.
• Checking a GitHub issue or PR comment before submitting it.Comment boxes render GFM live, but it's easy to lose track of exactly how a nested list or an inline code span with a backtick inside it will actually come out — previewing first avoids the edit-after-posting cycle.
• Reviewing someone else's Markdown before merging it.The raw-HTML escaping matters most here — you're rendering content you didn't write, and a safe-by-default converter is what makes that a reasonable thing to do at all.

A preview that only lives on screen is half the job. Once a document renders the way you want, the next step is usually getting that result somewhere else: copying the generated HTML markup directly into a CMS field or an email template, or exporting the rendered page as a PDF for a document that needs to leave the browser as a file rather than as markup. Both are the natural last step after the preview confirms the markdown to html conversion is correct — there's no reason to trust the export before you've seen the render.

And because the tool runs entirely client-side, none of that Markdown — draft documentation, an unreleased README, a comment you haven't posted yet — is ever uploaded anywhere; the parsing, rendering and export all happen locally in your browser. If the document you're previewing is a revision of something that already exists, comparing the two versions directly is a separate job — the Text Diff Checker will show exactly which lines of Markdown source changed, which a rendered preview alone won't.