Markdown Cheat Sheet: Syntax, Tables, and Live Preview Guide

Markdown has become the universal writing format for software documentation, static blog engines, developer notes, and README files. Created in 2004 by John Gruber and Aaron Swartz, Markdown allows writers to format rich text documents using intuitive plain-text punctuation. Whether you are drafting notes, documenting code, or preparing web copy, keeping a comprehensive markdown cheat sheet on hand saves time and prevents rendering surprises across different platforms.

Because Markdown was initially specified informally, different platforms introduced conflicting syntax variations. Today, the modern standard is governed by two complementary specifications: the core CommonMark Specification and the GitHub Flavored Markdown (GFM) Specification.

In this guide, we provide a complete syntax reference, clearly distinguish standard CommonMark rules from GFM extensions, compare platform rendering quirks, report live parsing observations from our Markdown Previewer, and show you how to convert markdown to HTML.

Complete Markdown Syntax Cheat Sheet

The table below summarizes standard formatting rules, distinguishing core CommonMark syntax from GFM-only extensions:

CommonMark Core Syntax vs. GFM Extensions

Understanding the architectural distinction between CommonMark and GitHub Flavored Markdown prevents bugs when moving content between note apps, documentation sites, and code repositories.

The CommonMark Foundation

In 2014, a group of developers led by John MacFarlane, Jeff Atwood, and members of the Markdown community created CommonMark to solve the rampant ambiguity in John Gruber's original 2004 syntax description. The CommonMark spec defines precise parsing rules, with hundreds of worked examples, for core formatting:

• ATX headings (# through ######) and Setext headings (=== or --- underlines).
• Emphasis using asterisks (*) or underscores (_).
• Nested lists (indented by 2 or 4 spaces).
• Fenced code blocks with language identifiers.
• Indented blockquotes and hard line breaks (two trailing spaces or a backslash).

GitHub Flavored Markdown (GFM)

As stated in Section 1.1 of the official GFM specification: GFM is a formal specification based on the CommonMark Spec that defines the dialect supported for user content on GitHub.com. GFM is a strict superset of CommonMark. Every valid CommonMark document is valid GFM.

GFM adds four key syntax extensions:

1. Tables (Section 4.10): Column pipes with hyphens and alignment colons.
2. Task List Items (Section 5.3): Checkboxes inside list items (- [ ] and - [x]).
3. Strikethrough (Section 6.5): Double tildes (~~text~~) producing <del> tags.
4. Autolinks (Section 6.9): Recognizing raw URLs (like https://... or www....) without square bracket syntax.

Proprietary Platform Features (Not Standard GFM)

Certain features frequently seen on GitHub repositories are application-level post-processing extensions that are not part of the standard GFM spec:

• GitHub Alerts: Blockquotes beginning with > [!NOTE], > [!TIP], or > [!WARNING] render colored callout cards on GitHub. On standard Markdown parsers, they render as standard blockquotes with literal [!NOTE] text.
• Mermaid Diagrams: Code blocks marked ``` mermaid ``` render interactive vector flowcharts on GitHub. Standard markdown engines render them as raw text code blocks.
• Footnotes: Extended footnote references ([^1]) are supported in GitHub discussions and Kramdown, but are not in core CommonMark.

Testing Syntax in the Zynocode Markdown Previewer

To evaluate how these rules behave in a production client-side environment, we tested every syntax element inside our Markdown Previewer.

The tool parses Markdown with the open-source marked engine (gfm: true), then cleans the HTML with DOMPurify before showing it, so scripts, event handlers and javascript: links never reach the page:

Markdown Previewer Testing Matrix:
1. Headings (H1 to H6): Rendered as <h1>–<h6>.
2. Bold, italic and strikethrough: Rendered as <strong>, <em> and <del>.
3. Code blocks: Rendered in <pre><code>, with syntax colours for JavaScript, TypeScript, Python, JSON, Bash, CSS, HTML/XML and SQL.
4. Tables: Rendered as <table> with header and body rows.
5. Autolinks: Bare URLs become clickable links.
6. Task lists: Rendered as read-only checkboxes.
7. Images: Rendered, loaded lazily and without sending your page address to the image host.
8. GitHub alerts: Rendered as a normal blockquote with the literal [!NOTE] text.
9. Footnotes: Not rendered; [^1] stays as plain text.

The last two rows show the point of this guide: GitHub alerts and footnotes are not part of the GFM specification, so a standard GFM parser treats them as plain text.

The previewer also has a formatting toolbar (bold, italic, strikethrough, heading, link, code, lists, task lists, tables and code blocks), a word, character and reading-time counter, and buttons to copy the Markdown or the cleaned HTML, or to download either as a .md or .html file.

Platform Differences: GitHub vs. Notion vs. Reddit vs. Obsidian

Markdown engines handle spacing, line breaks, and shortcuts differently. Review these common platform behaviors:

1. GitHub

• Engine: Full GFM with custom post-processors.
• Line Breaks: In issues and comments, a single newline shows as a line break. Strict CommonMark needs two trailing spaces or a backslash for a hard line break, and an empty line for a new paragraph.
• Mentions and Issues: Auto-links #123 to pull requests and @username to profile pages.

2. Notion

• Engine: Proprietary block architecture.
• Behavior: Typing Markdown shortcuts (such as # , * , or [] ) converts the line immediately into a Notion visual block. You cannot edit the underlying plain-text Markdown directly.
• Tables: Notion uses native interactive databases rather than standard GFM pipe tables.

3. Reddit

• Engine: Reddit's own Markdown flavor.
• Behavior: Supports standard bold, italic, code, and tables. However, Reddit's mobile apps and desktop redesign often handle paragraph spacing and backslash escapes inconsistently compared to CommonMark.

4. Obsidian

• Engine: Extended CommonMark with wiki-link support.
• Internal Links: Supports double-bracket syntax ([[Note Title]]) for linking notes across a personal knowledge graph.
• Callouts: Supports GitHub-style callouts (> [!NOTE]) with custom collapsible panels.

Writing, Converting, and Publishing Markdown

Follow this practical workflow to take notes from initial drafting to published web content:

1. Draft in Split-Screen: Open our Markdown Previewer to write in the left pane while monitoring the live typography rendering in the right pane.
2. Check Word Counts: Before publishing articles or documentation, copy your draft into Word Counter to inspect character counts, paragraph density, and estimated reading time.
3. Compare Revisions: When collaborating or updating documentation, paste previous and new markdown versions into Diff Checker to inspect changes line-by-line.
4. Convert to Clean HTML: When publishing content to a custom CMS, email newsletter, or static website, use our Markdown to HTML converter to generate semantic, sanitized HTML code ready for direct embedding.

Conclusion and Next Steps

Markdown provides the fastest, most portable way to write structured content on the web. By relying on core CommonMark rules for universal formatting and using GFM extensions when targeting modern code platforms, your documents will render consistently across every platform.

To streamline your markdown authoring:

• Test and format your notes live using the Markdown Previewer.
• Export sanitized markup for your web projects with the Markdown to HTML tool.
• Track content length and reading metrics with the Word Counter.
• Inspect line-by-line document edits with the Diff Checker.