Markdown Previewer
{{ summaryPrimary }}
{{ summaryLine }}
{{ parserBadge }} {{ safetyBadge }} {{ metrics.wordCount.toLocaleString() }} words {{ metrics.headingCount.toLocaleString() }} headings {{ warnings.length }} note{{ warnings.length === 1 ? '' : 's' }}
Paste Markdown to see a sanitized live preview, generated HTML, and a source audit.
{{ sourceActionHint }}
{{ sourceStatus }}
Choose the flavor that best matches the place where this Markdown will be reviewed.
Control how raw HTML in the Markdown is handled before the browser preview renders it.
Add deduplicated heading IDs to the generated HTML and outline audit.
{{ heading_ids ? 'On' : 'Off' }}
Check Status Value Detail Copy
{{ row.check }} {{ row.status }} {{ row.value }} {{ row.detail }} 
{{ outputHtml }}
{{ resultJson }}
Tags: Devtools, Editor, Text
Export to PDF Fullscreen
Customize
Advanced
:

Markdown is readable as plain text, but the final page depends on the parser, the Markdown flavor, raw HTML handling, and link policy used at render time. A release note that looks tidy in a text editor can still produce a missing heading, unsafe link, broken table, or surprising task list.

Markdown source moving through parsing and HTML safety checks into a rendered preview

Previewing Markdown before publishing is most useful when the source contains mixed structures: headings, links, tables, checkboxes, code fences, block quotes, and raw HTML. These elements are easy to misread in plain text and can change the review experience once rendered.

A preview is still a local rendering pass, not a guarantee that every platform will match it. CommonMark core and GitHub-flavored Markdown differ on extensions such as tables and task list items, and publishing systems may add their own sanitization after Markdown becomes HTML.

Technical Details:

Markdown rendering has two major phases: source parsing and HTML safety handling. Parsing decides which text becomes headings, lists, tables, links, code blocks, and other structures. Safety handling decides what happens to raw HTML and potentially unsafe links before the preview is inserted into the page.

The selected flavor controls extension behavior. GitHub-flavored Markdown enables tables, task lists, strikethrough, and autolinks when the full parser is available. CommonMark core keeps extension behavior more conservative.

Rule Core:

Setting or Check Behavior Result to Review
Markdown flavor Uses GFM-style extension behavior or a CommonMark-style core parse. Preview parser reports whether the full parser or fallback parser handled the source.
HTML safety Sanitize cleans rendered HTML, Escape shows raw tags as text, and Strip removes raw tags before parsing. HTML safety reports raw tag counts and unsafe-link neutralization.
External links Secure mode adds new-tab behavior and rel values to external HTTP and HTTPS links. JavaScript links are removed or neutralized. Links reports total links, external links, and secured external links.
Heading anchors Generated heading IDs are slug-style, accent-folded, and deduplicated when repeated headings appear. Heading outline lists mapped headings and their levels.
Source Audit Counts words, bytes, lines, headings, lists, tables, code blocks, task items, images, and warnings. Review notes summarizes missing H1, multiple H1, unsafe links, raw HTML, and unclosed code fences.

Files are loaded locally from MD, Markdown, or TXT inputs and are limited to 1 MB. The rendered preview, formatted HTML, source audit, and JSON output are all rebuilt from the same current source and settings.

The reading-time estimate uses a 225 words-per-minute review pace. Treat it as a planning cue for editorial review, not as an accessibility or comprehension measure.

Everyday Use & Decision Guide:

Paste the full document when structure matters. A single paragraph cannot reveal whether the heading outline, task list, links, tables, and code fences work together.

Use GitHub-flavored Markdown for README-style content, issue templates, release notes, and docs that rely on tables or task list items. Use CommonMark core when the destination is stricter or when you want to avoid relying on extensions.

  • Keep HTML safety on Sanitize rendered HTML when the source may contain raw tags.
  • Choose Escape raw HTML as text when reviewers need to see tags without rendering them.
  • Check Heading outline before copying HTML for a document that needs anchors or a table of contents.
  • Review Links when external references should open in a safer new tab.
  • Treat Review notes as a reason to inspect the source, especially for unclosed fences or unsafe links.

A clean preview means the current parser and safety settings produced usable HTML. Before publishing in another CMS or repository, compare a small sample there when tables, raw HTML, or heading IDs are important.

Step-by-Step Guide:

  1. Paste Markdown into Markdown source, or use Browse MD for an MD, Markdown, or TXT file under the local file limit.
  2. Choose Markdown flavor based on the target renderer: GFM for extension-heavy docs or CommonMark core for conservative output.
  3. Set HTML safety. Use sanitize for normal review, escape to display raw tags, or strip to remove raw tags before parsing.
  4. Choose the External links policy and turn Heading anchors on when generated IDs should appear in HTML Markup.
  5. Inspect Rendered Preview first, then open Source Audit for counts, warnings, heading outline, and link checks.
  6. If Review notes reports unsafe links, raw HTML, missing H1, multiple H1 headings, or an unclosed code fence, fix the source before copying HTML Markup.

Interpreting Results:

Rendered Preview shows what the current page will display after parsing and safety handling. HTML Markup shows the formatted HTML fragment generated from that same pass.

The most important false-confidence risk is treating sanitized preview as full security approval. Sanitization reduces risky rendering in this context, but publishing systems still need their own review, encoding, and content rules.

Use Source Audit to find concrete review triggers. A missing H1, multiple H1 headings, an unclosed code fence, or unsafe link references should be fixed in the Markdown source before the rendered result is trusted.

Worked Examples:

A release note with # Release notes, a checked task list, a status table, an external link, and a fenced JavaScript block should produce headings, one table, one code block, task-item counts, and secured external-link counts in Source Audit.

A document that starts with ## Migration but has no # heading still renders, but Review notes reports No H1 heading detected. Add a single H1 when the destination expects a page title.

A source link such as [bad](javascript:alert(1)) should not be trusted because it looks like ordinary Markdown. The audit counts it as an unsafe link reference, and the link is removed or neutralized before preview output.

FAQ:

Why does the preview differ from my CMS?

The CMS may use a different Markdown flavor, sanitizer, heading-ID rule, or link policy. Compare a small sample in the target system when these details matter.

What does the fallback parser mean?

Preview parser reports fallback when the full parser is unavailable. The fallback covers common Markdown structures, but GFM extension behavior may be less complete.

Is sanitized preview the same as a security review?

No. It is a safer preview setting for this page. It does not replace publishing-system sanitization, output encoding, permissions, or review of untrusted content.

Why did my file fail to load?

The loader accepts text-like MD, Markdown, or TXT files under 1 MB. Other extensions, non-text file types, or larger files trigger a local file error.

Glossary:

Markdown flavor
The syntax rules used to turn Markdown source into HTML.
Raw HTML
HTML tags typed directly into the Markdown source.
Sanitize
Clean rendered HTML by removing unsafe elements, attributes, or link targets before preview display.
Heading anchor
An id added to a heading so another link can jump to that section.

References: