Markdown Preview — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About Markdown Preview
Markdown is a plain-text format that compiles to HTML — designed in 2004 by John Gruber to be readable as-is and to render to clean structured markup. Two decades later it's the default for README files, technical docs, blog posts on most platforms, and pretty much every "text input that becomes formatted output" workflow. This previewer renders markdown live; what follows is the dialect map and the gotchas that make markdown look broken when it isn't.
John Gruber's original 2004 spec was deliberately under-defined — he focused on the common cases (headings, lists, links, emphasis, code blocks) and left the edges to each implementation. As a result, every major platform extended it differently. **CommonMark** (2014) is the modern attempt to standardise — strict parsing rules, well-defined edge cases. **GitHub Flavored Markdown (GFM)** is CommonMark + tables + task lists + strikethrough + autolinks + emoji shortcodes; what GitHub README files use. **Markdown Extra** (PHP) added footnotes and definition lists. **MultiMarkdown** added tables, footnotes, citations. Every static site generator (Jekyll, Hugo, MkDocs) ships its own variant.
This previewer renders **GFM-flavoured markdown** because that's what the majority of users in 2026 are writing. Tables, task list checkboxes, fenced code with language hints, autolinks — all supported. If your destination uses a different dialect (Pandoc with academic extensions, Discord with their custom subset, Slack with their not-quite-markdown), test there before assuming the preview matches.
The big three differences across dialects: (1) line break behaviour — original markdown collapsed single line breaks into spaces; GFM treats them as actual breaks. (2) Table syntax — only some dialects support pipe-tables; some require an extension. (3) Code block fencing — backticks vs. tildes vs. indentation. If your markdown looks broken in a different tool, those are the three things to check first.
After two decades, the most common markdown bugs are still the same five:
**Reference-style links** keep your prose readable when there are many links: write `[Click here][docs]` in the text and `[docs]: https://example.com/docs` at the bottom of the file. Every link to the same destination becomes a one-letter reference; updates happen in one place. Especially useful for long technical documents where the same link appears repeatedly.
**Footnotes** (GFM, MultiMarkdown, Pandoc — not in CommonMark): `Some claim.[^1]` then `[^1]: The supporting source.` at the bottom. Renders as a superscript link to a numbered list at the page bottom. Cleaner than parenthetical citations for technical writing.
**Task lists** (GFM): `- [ ] todo` and `- [x] done` render as checkboxes. GitHub makes them clickable in issues and PRs. Used heavily in pull request templates and README to-do lists.
**Tables with alignment**: `| Header |` with `| ---: |` (right-align), `| :--- |` (left-align), `| :---: |` (center). Default is left-align; right-align numeric columns for readability.
**Fenced code with language hint**: ```` ```python ```` instead of just ```` ``` ```` enables syntax highlighting in GitHub, GitLab, most static site generators, and this previewer. Always add the language hint — even "text" or "plain" beats no hint when consistency matters.
**Tight vs loose lists**: a list with no blank lines between items renders "tight" (no `<p>` wrapping each item, smaller line height); with blank lines between items it renders "loose" (each item gets `<p>` tags, more spacing). Pick by the visual density you want — both are valid.
Why does my GitHub README render differently here?
GitHub uses GFM with their custom emoji shortcode set, autolink behaviour, and security sanitisation. This previewer uses GFM but doesn't replicate every GitHub-specific extension (custom alert syntax `> [!NOTE]`, GitHub mentions `@user`, issue references `#123`). For pixel-perfect GitHub preview, GitHub itself is the only authoritative source — drag-drop your README into a draft issue or use VS Code's GitHub Markdown Preview extension.
Can I include math (LaTeX) in markdown?
Not natively — markdown has no math syntax. Many platforms add it: GitHub renders `$inline$` and `$$display$$` LaTeX in markdown via KaTeX since 2022. Pandoc, MkDocs Material, and most academic-focused renderers also support it. This previewer doesn't render math — paste into a math-aware renderer if your document uses LaTeX.
What about diagrams (Mermaid, PlantUML)?
GitHub renders Mermaid diagrams in fenced ```` ```mermaid ```` blocks since 2022. Many static site generators support both Mermaid and PlantUML. This previewer renders the Mermaid block as code with no diagram. For diagram preview, the destination platform's preview is the test.
Is markdown the same as Obsidian-flavoured markdown?
Mostly yes — Obsidian uses GFM as a base, with extensions for `[[wiki-links]]` between notes, embedded transclusion `![[note]]`, and custom callouts. The wiki-link syntax doesn't render anywhere outside Obsidian. If you're writing notes that you'll later publish, avoid `[[wiki-links]]` and use standard `[link text](url)` syntax for portability.
How do I escape a literal asterisk in markdown?
Backslash-escape: `\*` produces a literal `*`. Same for `_`, `[`, `]`, `(`, `)`, `#`, `+`, `-`, `.`, `!`. Inside fenced code blocks (` ``` ` blocks), nothing needs escaping — the entire block is treated as literal text.