Markdown Editor & Preview

Markdown Editor & Preview

Write and preview Markdown with live rendering. GitHub Flavored Markdown support. Free online Markdown editor with syntax highlighting

Markdown looks portable until you ship a README that renders fine on GitHub and breaks on npmjs.com. The differences are not "minor formatting" — table support, autolinks, task lists, and HTML pass-through diverge between CommonMark, GitHub Flavored Markdown (GFM), and the npm registry's sanitizer. This editor renders with markdown-it + GFM extensions in your browser, matching what GitHub actually shows, and flags syntax that will fail on stricter renderers.

Which dialect are you actually writing?

  • CommonMark — the strict reference spec. Headings, paragraphs, code blocks, links, images, basic emphasis, ordered/unordered lists. No tables, no task lists, no strikethrough, no autolinks.
  • GitHub Flavored Markdown (GFM) — CommonMark + tables, task lists ([ ] / [x]), strikethrough ~~text~~, autolinked URLs, footnotes, and tagged code-block highlighting. The de-facto default on GitHub, GitLab, and most static site generators.
  • MultiMarkdown / Pandoc — adds definition lists, citations, math via $...$, footnote syntax variants. Used in academic writing; not portable to GFM consumers.
  • Markdown Extra — older PHP-Markdown extensions. Tables (different syntax than GFM), attribute blocks {#id .class}. Rare in 2026 outside legacy PHP CMS.

Working example: a non-portable table

Input

| Tool | Speed | Notes |
|------|------:|-------|
| jq   |  fast | streaming |
| python | slow | full ast |

Output

GFM render:
  | Tool   | Speed | Notes     |
  |--------|------:|-----------|
  | jq     |  fast | streaming |
  | python |  slow | full ast  |

CommonMark strict render:
  Renders as a single paragraph with literal pipes and dashes — tables are not in spec.

NPM registry render (as of 2025):
  Renders as a table but strips column alignment.

Tables are the #1 source of "works on GitHub, broken on PyPI/npm/Cargo.io". If your README needs to render on multiple registries, test on each, or fall back to definition lists and plain bullet lists.

Features and their portability

  • Headings (# H1 / ## H2) — portable everywhere.
  • Fenced code blocks (```lang) — universal. Language tags for highlighting depend on the renderer's highlighter (Prism, highlight.js, Shiki). Unknown languages render as plain code, not error.
  • Task lists (- [ ] / - [x]) — GFM only. Plain text in strict CommonMark.
  • Footnotes ([^1] inline, [^1]: text at the bottom) — GFM and Pandoc, not strict CommonMark. Mostly portable in 2026.
  • Math ($x = y$ inline, $$ block $$) — Pandoc, MathJax-rendering sites (Discord, some static generators). Not GitHub by default; GitHub added LaTeX rendering in 2022 but with $$...$$ block syntax only.
  • Inline HTML — most renderers allow safe-subset HTML pass-through. NPM and PyPI strip more aggressively. If you write <details> blocks, test them where they will ship.

When to reach for this tool

  • You are writing a README and want to see the rendered output before pushing — without a commit-push-refresh loop.
  • You inherited documentation written in pre-GFM dialect and want to see what renders versus what shows as raw text on a modern viewer.
  • You are debugging "my README looks fine on GitHub but blank on npm" — compare the renders to spot the unsupported syntax.
  • You are drafting a blog post for a static site generator (Hugo, Astro, Next.js MDX) and want to verify code-block fences and front-matter render correctly.

What this tool will not do

  • It will not render Mermaid or other extension diagrams. GitHub renders ```mermaid blocks as diagrams; most editors render them as plain code. For diagram preview, use a Mermaid-specific tool.
  • It will not check links. A broken [Title](https://example.com) renders fine in any markdown tool. Use a separate link checker against your file.
  • It will not perfectly emulate every renderer. Each major host (GitHub, GitLab, npm, PyPI, Bitbucket) has its own quirks. This tool matches GitHub closely; for other hosts, render on the host.

Markdown rendering happens entirely in your browser. Draft documents, internal notes, and unpublished work stay local.

Frequently asked questions

Why is my code block not getting syntax highlighting?

Either the language tag is missing (```ts not ```), the renderer does not know the language (write tsx or typescript, not typesript), or the renderer's highlighter does not bundle that grammar by default. Highlight.js auto-detects 30+ languages; Prism requires explicit imports.

How do I add a line break without starting a new paragraph?

Two trailing spaces at the end of a line force a line break in CommonMark. GFM also supports a backslash at end of line (\). Most editors strip trailing whitespace on save, so the backslash form is more portable.

Why does my README show raw HTML tags on PyPI?

PyPI sanitizes HTML aggressively. Tags like <details>, <summary>, <kbd>, and many attributes are stripped. Either use plain markdown for cross-registry READMEs, or maintain a separate "long_description" tailored for PyPI rendering.

How do I link to a section in the same document?

Headings get auto-generated anchor IDs: # My Heading becomes #my-heading (lowercased, spaces → hyphens, punctuation stripped). Link with [text](#my-heading). Anchor algorithm varies slightly between renderers (GitHub differs from GitLab on emoji handling).

What is "front matter" and does this preview support it?

YAML front matter (--- ... --- at the very top of a file) is metadata used by static site generators. Markdown parsers ignore or display it. For Hugo / Jekyll / Astro, the SSG strips front matter before rendering; in a generic preview it shows as a horizontal rule + YAML text unless explicitly stripped.

Should I write Markdown with hard line breaks at 80 chars?

For source-control diffs, yes — hard-wrapping at 80-100 chars produces cleaner PR diffs because line moves are visible. For prose-only readers, no — modern editors wrap visually. Most teams pick a convention; the rendered output is identical either way.

Related tools

Last updated · E-Utils editorial team