MarkdownPaper Open reader

Guide

Sample Markdown file

One Markdown file that uses nearly everything Markdown can do: headings, emphasis, nested and task lists, an aligned table, highlighted code, footnotes, mathematics, a Mermaid diagram, and a few pieces of HTML that a safe renderer must refuse to run. It is the file MarkdownPaper tests itself against on every change, published as it is.

Download sample-markdown-file.md, or open it in the reader to see it typeset. It is free to use for testing any editor, renderer, static site generator or CMS.

3 min read4 sectionsUpdated 29 Sep 2026

What the file covers

  • Inline formatting: bold, italics, inline code, strikethrough and links.
  • Lists: bulleted, numbered and nested lists, and a task list with ticked and unticked boxes.
  • A table with left, centred and right aligned columns.
  • Code: a fenced TypeScript block that should be highlighted, and a plain block that should not.
  • Math: an inline formula and a displayed equation, written for KaTeX.
  • A Mermaid diagram, which should draw as a diagram rather than show as code.
  • A blockquote and footnotes, whose links should reach their notes and come back.
  • Untrusted HTML: a script, a javascript: link and an iframe, none of which should do anything.

How to test a renderer with it

  1. Open the file in the renderer you want to check.
  2. Read it top to bottom. Every section should appear as formatted text, not as the symbols that wrote it.
  3. Check that the table stays readable and that long code scrolls sideways instead of breaking the page.
  4. Confirm the equation and the diagram are drawn rather than left as fenced text.
  5. Follow a footnote reference down to its note and back.
  6. Make sure the script did not run, the javascript: link does nothing, and no iframe appeared.
  7. Print it, or save a PDF, and look at the page breaks and margins.

What a pass looks like

A pass means the information is all there, readable and safe. It does not mean every renderer's typography matches: fonts, spacing and colours are choices. What must hold is that raw HTML cannot run code, that wide tables and code can still be read, that footnote links reach their notes, and that a printout carries the document and none of the application around it.

The parts renderers most often get wrong

Tables lose their alignment, so the numbers in a right aligned column stop lining up:

You write

| Item   | Qty | Price |
| :----- | :-: | ----: |
| Paper  | 2   | $4.00 |
| Ink    | 10  | $12.50 |

You see

ItemQtyPrice
Paper2$4.00
Ink10$12.50

Footnotes arrive as plain text, or their links point nowhere:

You write

A claim that needs a source.[^1]

[^1]: The source, gathered at the end of the document.

You see

A claim that needs a source.1

Footnotes

  1. The source, gathered at the end of the document. ↩

And raw HTML is passed straight through. A safe renderer keeps the text and removes what could act on your machine: here the script is gone, the link has lost its address, and the iframe was never drawn.

You write

<script>alert('this should never run')</script>

<a href="javascript:alert(1)">A link that should go nowhere</a>

<iframe src="https://example.com"></iframe>

You see

A link that should go nowhere

For the syntax behind each feature, see the Markdown cheat sheet.