Markdown Extended Syntax: Tables, Task Lists, Footnotes, and Code Fences Explained

Basic Markdown covers headings, bold, links, and lists — everything John Gruber defined in 2004. But the features most developers actually reach for daily live outside that original spec: tables, checkboxes, footnotes, and fenced code blocks. These are collectively called "extended syntax," and knowing exactly how they work (and where they differ across renderers) saves a lot of debugging time.

GitHub Flavored Markdown (GFM), which introduced tables and task lists as formal elements, was formalized in 2017. By 2023, the GFM spec is implemented by more than 30 major editors, CI tools, and documentation platforms — making it the de-facto baseline for extended syntax.

GFM Tables: Pipes, Dashes, and Alignment

A Markdown table is written with pipe characters (|) as column dividers and a separator row of dashes to mark the header. Every column needs at least three dashes in the separator row.

Real input:

| Language | First release | Typing   |
|----------|--------------|----------|
| Python   | 1991         | Dynamic  |
| Rust     | 2015         | Static   |
| Go       | 2009         | Static   |

Rendered output (in any GFM-compatible renderer):

| Language | First release | Typing | |----------|--------------|----------| | Python | 1991 | Dynamic | | Rust | 2015 | Static | | Go | 2009 | Static |

Column alignment is set in the separator row: a colon on the right means right-align (:---:), on both sides means center, and the default (no colon) means left-align. Extra spaces inside cells are trimmed automatically, so column widths in the source are cosmetic only.

One friction point I hit often: the outer pipes are technically optional in some renderers but required in others. The safe habit is to always include them. For complex table layouts, Toolora's Markdown Table Generator is worth bookmarking — it handles alignment columns and multi-row editing visually without keeping track of pipe counts manually.

Task Lists: Checkboxes Without JavaScript

Task lists use a special list item prefix: [ ] for unchecked and [x] for checked. They are rendered as actual checkbox elements in GitHub, GitLab, and most modern docs platforms.

Input:

- [x] Write unit tests
- [x] Update CHANGELOG
- [ ] Deploy to staging
- [ ] Notify the team

Output: A bulleted list where the first two items show a filled checkbox and the last two show empty boxes.

The syntax is strict about spacing: there must be exactly one space inside the brackets for an unchecked item ([ ]), and the x can be either lowercase or uppercase ([X] also works on GitHub). A typo like [- ] or [] silently falls back to a regular list item instead of rendering a checkbox, which is a common source of confusion when copy-pasting from word processors.

Task lists are primarily a read-and-click feature in GitHub issues and pull requests — clicking a rendered checkbox actually updates the Markdown source. Outside of GitHub, they usually render as visual checkboxes without the click-to-toggle behavior.

Footnotes: Numbered References Without Cluttering the Body

Footnotes in extended Markdown (supported by Pandoc, GitHub since 2021, and several static site generators) let you add numbered citations or clarifications without interrupting the prose flow.

Input:

The library uses the BLAKE3 hashing algorithm[^1] for content addressing.

[^1]: BLAKE3 achieves throughput of 6.7 GiB/s on a modern x86 core — roughly 4× faster than SHA-256 on the same hardware, per the BLAKE3 paper (2020).

Output: The [^1] in the body becomes a superscript link (¹) pointing to a footnote block rendered at the bottom of the document. Clicking the superscript jumps you to the definition; a back-arrow link returns you to the reference point in the text.

I tested this in Obsidian, GitHub, and a Pandoc-to-PDF export in the same week, and the rendering behavior differs in one subtle way: GitHub puts all footnotes in a single <section> block at the end of the page regardless of where the definitions appear in the source, while Pandoc respects the placement in the raw file. The label (e.g. [^1]) can be any alphanumeric string — [^note-bplusplus] is valid — though numeric labels are the most common convention.

Fenced Code Blocks: Language-Aware Highlighting

Fenced code blocks use triple backticks ( ` ) or triple tildes (~~~) to wrap code, with an optional language identifier on the opening fence. The identifier is used by renderers to pick a syntax-highlighting grammar.

Input:

def greet(name: str) -> str: return f"Hello, {name}!"

print(greet("world"))

Output: A syntax-highlighted block where def, str, return, and print are colored according to the Python grammar.

The language identifier after the opening fence is just a hint — the renderer ignores it if the grammar isn't available, falling back to unhighlighted monospace. Supported identifiers vary: js and javascript both work in GitHub; tsx works in VS Code and Astro docs but not in older GitHub renderers. For shell commands, sh, bash, and shell are all common choices, with bash being the most widely recognized.

Indented code blocks (four spaces or one tab) still work in CommonMark but are invisible to syntax highlighters and are generally considered legacy syntax. The fenced form is the one you should reach for in every new document.

Choosing the Right Renderer

Extended syntax isn't a single standard — it's a family of overlapping extensions. Before committing to footnotes or certain table features, it helps to check which renderer your platform uses.

Quick cheat: if a platform renders [x] task lists, it almost certainly supports GFM tables and fenced code blocks too. Footnotes are the least universally supported — GitHub added them in 2021, Pandoc has had them for years, but many lightweight blog engines and older wikis still omit them.

For everyday Markdown authoring and quick experiments, Toolora's Markdown Editor renders GFM in real time so you can verify table formatting or footnote rendering before pasting into a target platform. If you're working from a reference rather than a live editor, the Markdown Cheat Sheet covers both basic and extended syntax side by side with examples for each rule.

A Few Rules That Trip People Up

The three most common mistakes I see with extended syntax:

1. Missing the separator row entirely in tables. Without |---|, the pipes are rendered as literal text, not a table.
2. Putting a blank line between a footnote reference and its definition. Both the inline [^label] and the block [^label]: ... work anywhere in the document — blank lines between them do not break anything. The confusion usually comes from expecting the definition to appear right after the reference.
3. Using language identifiers with dashes when the renderer expects plain names. c-sharp instead of csharp or cs is a common example. When in doubt, use the shortest, most common form of the language name.

Extended syntax makes Markdown a genuine documentation tool rather than just a formatting shortcut. Once you have the table separator row and code fence syntax memorized, the rest follows naturally.

---

Made by Toolora · Updated 2026-06-28