Markdown tables that look like tables
Markdown tables are easy to write and easy to mess up. The right alignment, the right header treatment, the right totals row — the difference between a screenshot of a CSV and a deliverable.
Basic syntax
| Column | Column | Column | | --- | --- | --- | | Cell | Cell | Cell | | Cell | Cell | Cell |
The separator row defines how many columns the table has. Rows that have fewer cells get padded with empty cells; rows with more cells get truncated. Pipes at the start and end of a row are optional in GitHub Flavored Markdown — but adding them makes the source much easier to read.
Alignment
Add a colon to the separator row to set column alignment:
| Left | Center | Right | | :--- | :---: | ---: | | A | B | 1,234 |
Numeric columns are auto-right-aligned by the converter even without the explicit colon — it scans the body cells, and if 60%+ parse as numbers, the column gets right alignment automatically. That covers most pricing and metrics tables without any manual work.
Totals rows
Toggle Bold last row (Total) on the table in the sidebar to render the last row in bold with a thin rule above it — the standard pricing-sheet treatment.
Four table styles
- Minimal — single rule above and below, single rule under the header. The default.
- Corporate — Minimal plus a tinted header row. Use this on proposals and contracts.
- Striped — alternating row tint. Best for long data tables.
- Bordered — full grid of hairlines. Best for invoices and structured numeric reports.
What goes wrong with tables
- Too many columns. If a table needs 6+ columns, it usually wants to be two tables.
- Mixed numeric formats."1200" in one row, "1,200" in another — pick one and stick with it.
- Long body text in cells. Tables work for short cells. Long cells should be paragraphs that reference a short-cell table.