Table generator
Processed in your browser · nothing is uploaded
Paste a CSV and get either a real HTML table — thead, tbody, th cells and every value escaped — or a Markdown table with its pipes padded into columns. The Markdown output detects a tab separator, which is what a spreadsheet copy puts on the clipboard; the HTML output reads commas, so swap the tabs first.
How to build a table
The two outputs fail in opposite ways when a table is written by hand, and that difference is most of what there is to know about them.
HTML fails silently
A cell containing <, & or a quote produces markup a browser will still render, just not as the text you meant. The page comes up, nothing throws, and one cell has quietly eaten the rest of the row. Escaping every value is the reason to generate the markup instead of typing it.
Structure carries weight of its own. A screen reader uses the th elements to announce which column a cell belongs to as someone moves through the table, so a grid built entirely from td is navigable only by a person who can see it. A thead also lets the browser repeat the header row when a long table breaks across printed pages. The scrolling option solves the other problem every wide table has: a table will not shrink below the width of its content, so a wide one pushes the whole page sideways. Wrapping it in a block with overflow-x: auto confines the scroll to the table, which is what this site does with its own article tables.
Markdown fails loudly
Here the pipes are the syntax, and the separator row is the part that carries meaning. --- is a plain column, :--- left-aligns, ---: right-aligns and :---: centres, and those colons survive the alignment pass instead of being padded away. Get the number of separator cells wrong and the block does not render as a table at all, which is far and away the most common reason a pasted table comes out as a row of pipes.
Aligning the pipes changes nothing about how a table renders and everything about whether the source is readable. A table maintained by hand drifts out of alignment within a few edits, and an unaligned table is exactly where a missing cell hides, so the value shows up in a pull request rather than on the page.
One detail catches people building a table from data they copied: a range copied out of a spreadsheet arrives as tab-separated text, not as CSV. The Markdown output detects the tab. The HTML output splits on commas, so swap the tabs for commas first or you get one very wide column.
The one thing neither format can do is span cells. Markdown has no colspan, so a table that genuinely needs one belongs in HTML.
What people use it for
- Turning a CSV export into an HTML table with a real header row
- Wrapping a wide table so it scrolls itself instead of pushing the page sideways
- Lining up the pipes in a Markdown table so the diff reads
- Building a Markdown table from a pasted CSV or TSV block
- Escaping cells that contain angle brackets or ampersands before they break the markup
- Finding the missing cell in a Markdown table that stopped rendering
- Putting a spreadsheet range into a README or a pull request description
Questions
A cell containing <, & or a quote produces broken markup by hand, and the failure is silent.
Screen readers use th elements to announce the column for each cell, and browsers repeat thead when printing across pages.
Wraps the table in a block with overflow-x: auto, so a wide table scrolls itself instead of pushing the page sideways.
For the Markdown table, yes: the tab separator a copied range puts on the clipboard is detected. The HTML output splits on commas, so replace the tabs first.
No. It only makes the source readable, which is where the value is, in a diff.
Put a colon at the right of the separator: ---:. Left is :---, centre is :---:.
Usually the separator row has the wrong number of cells, or there is no blank line before the table.
Not in Markdown, which has no colspan. Use the HTML output if you need one.
Yes. Both outputs treat it as the header row.
No. They are a GitHub Flavored Markdown extension, which is why some renderers ignore them.
No. It carries the class you type and no CSS, so it inherits whatever your page already applies to tables.
By hand, as a caption element immediately after the opening table tag. A screen reader announces it before the table, which is worth the extra line on anything non-obvious.
No. Everything runs in your browser, which matters when the table holds customer data.