Download Sample Markdown Files

Sample Markdown files are used whenever you need a realistic .md document without writing one from scratch. Common use cases include testing static site generators (Jekyll, Hugo, Astro, Eleventy, Next.js), verifying that a Markdown renderer handles headings, tables, code blocks, and lists correctly, seeding a CMS that stores content as Markdown, testing note-taking app importers (Obsidian, Notion, Bear), checking that a README preview renders properly, and providing example fixtures in developer documentation.

The flavor-specific files are especially practical — a file that uses GFM task lists or strikethrough will break a CommonMark-only renderer, and a file with MultiMarkdown footnotes will fail silently in a parser that doesn't support them. Having correctly-structured examples for each flavor makes it straightforward to identify where your parser falls short.

CommonMark is a strict, unambiguous specification for core Markdown — headings, paragraphs, bold, italic, links, images, code spans, fenced code blocks, and lists. It deliberately excludes extensions so that any conforming parser produces identical output. GitHub Flavored Markdown (GFM) is a superset of CommonMark that adds tables, task lists, strikethrough (~~text~~), autolinks, and disallowed HTML filtering. If you're targeting GitHub READMEs, GitHub Pages, or most modern CMSs, GFM is the right choice. If you're building a tool that needs to be strictly portable across parsers, CommonMark is safer.

Front matter is a block of metadata at the very top of a Markdown file, enclosed by delimiters, that tells a static site generator or CMS about the document — its title, date, tags, author, layout template, and so on. The most common format is YAML front matter, enclosed by --- lines, which is used by Jekyll, Hugo, Astro, Eleventy, VuePress, and most other static site generators. TOML front matter (enclosed by +++) is used by Hugo as an alternative. JSON front matter (enclosed by {}) is less common but supported by some toolchains. Parsers that don't understand front matter will render it as a visible horizontal rule and paragraph, which is a common rendering bug worth testing for.

Footnotes let you add a numbered reference inline with [^1] and define the footnote content elsewhere in the document with [^1]: Footnote text here.. Renderers that support them display a superscript number that links to the footnote at the bottom of the page. Pandoc and MultiMarkdown both support footnotes natively. GitHub's Markdown renderer added footnote support in 2022. CommonMark does not include footnotes in its spec — a CommonMark parser will render the [^1] syntax as literal text rather than a footnote reference. If your footnotes aren't rendering, check whether your parser explicitly lists footnote support.

Keep a Changelog (keepachangelog.com) is a widely adopted convention for writing CHANGELOG.md files. It structures changes under version headings (e.g., ## [1.2.0] - 2024-06-15) with sub-sections for ### Added, ### Changed, ### Fixed, ### Removed, ### Deprecated, and ### Security. An [Unreleased] section at the top collects changes for the next version. The format is plain Markdown with no special extensions, which means any Markdown parser can render it. Many changelog parsers and release automation tools (semantic-release, release-please, changie) also parse this format to generate release notes automatically.

Tables are not part of the CommonMark specification — they are a GFM extension. A CommonMark-only parser will render a Markdown table as a paragraph of pipe characters and dashes rather than an HTML table. Even among parsers that support tables, there are differences: GFM requires at least one cell in each column of the header separator row (| --- |), but is otherwise flexible about spacing and alignment. Some parsers are stricter about requiring the outer pipe characters at the start and end of each row. If your tables aren't rendering, the most common fix is switching to a parser that explicitly supports GFM or PHP Markdown Extra table syntax.

Pandoc is a universal document converter that can transform Markdown into PDF, DOCX, HTML, LaTeX, ePub, and dozens of other formats. Because Pandoc is used for academic writing and publishing, its Markdown flavor extends GFM with features that are important for scholarly documents: inline LaTeX math ($E = mc^2$ and $$...$$ for display math), definition lists, numbered example lists, line blocks, fenced divs (for custom HTML wrappers), header attributes, and more. Pandoc Markdown is the right choice when you're generating PDFs from Markdown with equations or complex typography, or when you're writing academic papers or technical documentation that needs to be converted to multiple output formats.

Yes. For Obsidian, use the GFM templates — Obsidian renders GFM and also supports wiki-style links ([[page name]]) and callout blocks (> [!NOTE]), but standard GFM files import without issues. For Notion, the plain templates without front matter work best, since Notion's Markdown importer doesn't parse front matter. For Bear or iA Writer, the standard GFM or CommonMark templates are appropriate. For Roam Research, plain Markdown with no front matter is the safest choice. The Feature Showcase file is particularly useful for testing how a specific app handles edge cases — nested lists, code blocks with language hints, and tables are the most common rendering differences between apps.