Free Markdown Table Generator
Build Markdown tables visually with a spreadsheet-style editor.
Click L / C / R below each column header to set alignment (Left, Center, Right).
Markdown Output
Markdown Tables: A Convention That Was Never in the Original Spec
A surprising piece of Markdown trivia: tables were not in the original Markdown specification. John Gruber's first Markdown release on 15 March 2004 (with the canonical 1.0.1 following on 17 December 2004) covered headings, paragraphs, lists, code blocks, blockquotes, links, images, emphasis and inline HTML, but explicitly omitted tables. Gruber considered structured data tables out of scope for "lightweight" markup designed to read well as plain text; the conscious design choice was that anything table-like should be authored in HTML directly. Markdown tables, as we now know them, came from extension dialects.
The pipe-table syntax was first introduced by Michel Fortin in PHP Markdown Extra on 29 July 2005. Extra added syntax for tables, definition lists, fenced code blocks, footnotes, abbreviations, and the {#id .class} attribute syntax for headings, features that explicitly extended Markdown beyond Gruber's original scope. MultiMarkdown (Fletcher T. Penney, May 2007) adopted Extra's table syntax and added support for column alignment via colons in the separator row. GitHub Flavored Markdown (GFM) incorporated the syntax as a standard extension in 2013; the formal GFM spec 0.29-gfm dated 6 April 2019 documents the canonical table syntax. CommonMark (Atwood + MacFarlane, first release 25 October 2014, current 0.31.2 dated 28 January 2024) does not include tables in the core spec (they remain a GFM extension. So when you write a Markdown table you're using "GFM tables", not "Markdown tables") the distinction matters because some pure-CommonMark processors (Pandoc with strict CommonMark mode, Discount, certain documentation generators) won't render the pipe syntax.
The Pipe-Table Syntax, Mechanically
A GFM table consists of three parts: a header row with cells separated by pipes (|), a delimiter row immediately below using dashes (---) for each column, and zero or more data rows with the same pipe-separated structure. Leading and trailing pipes on each row are optional but conventionally included for readability. Column alignment is specified by colons in the delimiter row: :--- for left-align (the default), :---: for center, ---: for right. The minimum viable table looks like this in source: | Header | Header | on line 1, | --- | --- | on line 2, | Cell | Cell | on line 3 onwards. Cell content can include any inline Markdown formatting (bold, italic, links, code spans, images) but cannot include block-level elements (lists, code blocks, blockquotes). Line breaks within a cell need to be encoded as <br> tags rather than literal newlines, since literal newlines would break the table structure. Pipe characters inside cell content must be escaped as \|: otherwise the parser treats them as column separators and the row's column count goes wrong. Most parsers tolerate misaligned column widths; the source | a | b | and | aaa | b | render identically, even though the latter looks more "right" in the source. This tool always emits aligned-width source for readability, but renders the same as compact source.
Where Tables Render and Where They Don't
Renders correctly: GitHub (issues, pull requests, READMEs, wiki pages, discussions, code reviews, comments anywhere), GitLab (same surfaces), Bitbucket, Stack Overflow, Reddit (when GFM is enabled in the subreddit, which is most of them), Discord (in code-block context only, full GFM tables don't render in chat messages but markdown-it processes them in the docs surface), Notion (with its own table import), Obsidian, Logseq, Bear, most static-site generators (Hugo, Jekyll, Eleventy, Astro with the remark-gfm plugin, Next.js MDX), VS Code's preview, GitHub Pages, Read the Docs (depending on configuration). Does not render correctly: strict CommonMark (Pandoc with the commonmark reader and no extensions, Discount C parser without the pipe-table flag), Slack (renders Markdown subset but not tables), most email clients (the rendered HTML in email is structurally fine but inline-styled, not Markdown), older WordPress installations without a Markdown plugin. The general rule: if your destination is a developer-oriented platform (GitHub family, technical documentation), GFM tables work. If your destination is a general-audience platform (Slack, email, Twitter), assume tables won't render and either pre-render to an image or rewrite as a list.
Alternative Markdown Table Syntaxes
The pipe-table format dominates because of GitHub's reach, but it isn't the only Markdown table syntax. Pandoc simple tables use blank-line-and-dashes separators and align columns by visual position rather than pipes, much more readable for narrow tables but harder to author by hand. Pandoc multi-line tables support cells that span multiple lines, important for long descriptive content that doesn't fit on one row. Pandoc grid tables use ASCII-art borders (+---+---+) which look painful to maintain by hand but are easy for tools to emit. reStructuredText (Sphinx) uses grid tables exclusively, every Python project's documentation is written this way. AsciiDoc uses a different pipe-prefix syntax (|===) optimised for technical-book authoring. HTML in Markdown is always available as the escape hatch: any Markdown processor passes raw HTML through, so when pipe tables aren't enough you can drop in a real <table> with full row/column spanning, semantic markup and CSS styling. The pipe-table syntax this tool generates is GFM-style, the most compatible choice for the modern developer ecosystem.
Common Use Cases
- GitHub README files. Comparison tables ("our library vs. alternatives"), feature matrices, supported-versions lists, contributor lists, command reference cards. Probably the single most common production use of GFM tables.
- Documentation and wikis. API reference tables (parameter name / type / description / default), configuration option tables, error code references, language-translation matrices. Read the Docs, MkDocs, Docusaurus, GitBook all support GFM tables.
- Comparison blog posts. "Framework X vs Framework Y" articles, hardware spec comparisons, pricing tier breakdowns. The pipe-table format is much more readable than ad-hoc paragraphs and renders cleanly on Medium, dev.to, Substack and personal blogs.
- Pricing pages. SaaS tier tables (Free / Pro / Enterprise across rows of features) work well in pipe-table form for quick draft-version mockups before commercial designers do the polished HTML version.
- GitHub issue templates. Bug report templates often include reproduction steps in table form (Step / Expected / Actual / Screenshot). Project board status tables for tracking sprint progress.
- Meeting notes and project plans. Action item tables (Owner / Action / Due Date / Status) in shared notes documents. Decision logs. Risk registers.
- CSV import. Many table generators offer CSV-to-Markdown import, paste a CSV, get a Markdown table. The reverse (Markdown to CSV) is also common when extracting structured data from documentation back into spreadsheet format.
The Width Problem and Other Constraints
Pipe tables have several inherent limitations worth knowing about. Column width is constrained by the longest cell content: a long URL or descriptive paragraph in one cell forces the entire column wide, which can produce unwieldy tables that don't fit on standard documentation page widths. The fix is either to truncate long content (linking elsewhere for detail) or to use HTML inline if you need wrappable cells. No row or column spanning: every cell occupies exactly one row and one column. Complex tables with merged cells need real HTML <table> with rowspan / colspan attributes. No nested tables: you can't put a table inside another table cell in Markdown. No block-level content in cells: no lists, no code blocks, no blockquotes inside a cell. Inline content (bold, italic, code spans, links, images) is fine but anything multi-line needs <br> tags. Header row is mandatory in GFM, there's no headerless table syntax. If you want a table without a visible header, leave the header cells blank but the row still has to be present. Alignment applies per-column to the entire column: you can't have different alignment for different cells in the same column. For sophisticated table layouts that exceed these constraints, the right tool is HTML in your Markdown source, not Markdown itself.
CSV ↔ Markdown Conversion
Most real-world tabular data lives in CSV files (spreadsheet exports, API responses, log analysis output), converting to and from Markdown is a common workflow. CSV → Markdown: parse the CSV (handling quoted fields with embedded commas, escaped quotes, line breaks within fields), then format each row as | value | value | with the appropriate header and delimiter rows. Most table generators including this one offer CSV import; for one-off conversions you can also use csvkit's csvlook command-line tool which produces a similar pipe-format output. Markdown → CSV: parse the GFM table back into rows and columns, then emit CSV with proper quoting. Useful when extracting structured data from documentation back into spreadsheet form for analysis. The Markdown-to-CSV direction is offered by tools like pandoc (with the right reader/writer combination), tableconvert.com, and various command-line utilities. The round-trip is lossy in one direction, formatting (bold, links, images) survives the CSV step intact only if you write the CSV cell content as raw Markdown text and treat the result as Markdown again.
Privacy: Why Browser-Only Matters Even Here
Tables don't seem like sensitive data, but the contents of tables often are. Project plans contain personnel decisions and unannounced features. Pricing tables contain commercial information. Comparison tables in unpublished blog posts reveal editorial positioning. Meeting note action items contain assignment and accountability information. Server-side table generators upload your data to a third party where it sits in logs. This tool runs entirely in your browser via JavaScript, verify in DevTools' Network tab while you edit cells, or take the page offline (airplane mode) after it loads and the editor still works. Safe for unpublished documentation drafts, internal project planning, comparison tables for blog posts not yet published, or any table content you wouldn't want copied onto a stranger's hard drive.
Frequently Asked Questions
What Markdown table syntax does this generate?
Standard GFM (GitHub Flavored Markdown) tables, formally specified in GFM 0.29-gfm dated 6 April 2019. The syntax: pipe-separated header row, separator row of dashes (with optional colons for column alignment), then pipe-separated data rows. This works on every GitHub-family platform (GitHub, GitLab, Bitbucket), most documentation generators (Hugo, Jekyll, Eleventy, Astro, MkDocs, Docusaurus), Reddit (in most subreddits), Notion, Obsidian, and dev.to / Hashnode / Medium-style platforms. It's worth knowing that pipe tables are not in core CommonMark, strict CommonMark processors (Pandoc with the commonmark reader, Discount without the pipe-tables flag) won't render them.
How do I set column alignment?
Click the L / C / R buttons below each column header. Internally, alignment is encoded in the delimiter row: :--- for left-align (also the default if no colons), :---: for center, ---: for right. The colons indicate which side of the dashes the alignment "leans" toward. Alignment applies per-column to the entire column, you can't have different alignment for different cells in the same column without dropping to raw HTML.
Can I import from CSV or paste from a spreadsheet?
CSV import is on the roadmap. For now, paste-from-Excel/Google Sheets often works because most spreadsheet apps put tab-separated data on the clipboard, which you can paste into individual cells. For bulk CSV import without manual paste, command-line tools like csvkit's csvlook produce similar GFM-table output, or pandoc can convert CSV to Markdown directly with pandoc --from csv --to gfm input.csv.
What about merged cells, nested tables, or block content in cells?
GFM pipe tables don't support these. Each cell occupies exactly one row and one column; no rowspan or colspan. No nested tables. No block-level content (lists, code blocks, blockquotes) inside a cell, only inline content (bold, italic, code spans, links, images, line breaks via <br>). For sophisticated table layouts that exceed these constraints, embed raw HTML <table> directly in your Markdown source, every Markdown processor passes HTML through unchanged. The trade-off is that the source becomes much harder to read and edit by hand.
Is there a limit on rows or columns?
This editor caps at 20 columns and 100 rows, more than sufficient for any documentation, README or comparison table use case. For genuinely large tabular data (hundreds of rows of structured information), you probably want a different format anyway: CSV for data analysis, JSON for API responses, or a real database table. Markdown tables shine for small-to-medium reference data where readability of the source matters; for big data they break down both visually and mechanically.
Are my table contents sent anywhere?
No. Generation runs entirely in your browser via JavaScript. The cells you edit and the Markdown output never cross the network, verify in DevTools' Network tab while you type, or take the page offline (airplane mode) after it loads and the editor still works. Safe for unpublished documentation drafts, internal project plans, pricing comparison tables not yet published, or any tabular content you wouldn't want copied onto a stranger's hard drive.