A Markdown table is one of the most useful structures in the format and one of the most annoying to type. The syntax is simple — pipes separate columns, a row of dashes separates the header from the body — but it is unforgiving: every row must have the same number of pipes, and a single missing pipe shifts every value after it into the wrong column. For a three-column table with five rows, that is twenty-odd pipes to count by hand, and the counting is exactly the kind of work humans do badly and generators do perfectly.

The Markdown Table Generator removes the counting. You specify the columns and rows, fill in the cells, and it produces a table with the pipes, dashes, and alignment row in place. You paste the result into your document, and it renders correctly the first time.

How the tool works

A Markdown table has three parts. The header row names the columns, with each name separated by a pipe character. The separator row follows immediately, with one group of dashes per column, also separated by pipes. The body rows follow, one per record, with one cell per column. An optional feature is the alignment marker in the separator row: dashes alone mean default alignment, a colon on the left (:---) means left-aligned, a colon on the right (---:) means right-aligned, and colons on both sides (:---:) mean centred. Alignment matters most for numbers, which read better right-aligned, and for text, which reads better left-aligned.

The generator's job is to assemble those three parts consistently. It ensures that every row has exactly as many cells as the header, that the separator row has exactly as many dash groups as there are columns, and that the pipes line up. Some generators also pad the cells with spaces so that the pipes align vertically in the source text. Padding does not affect rendering — a renderer ignores extra spaces inside cells — but it makes the source far easier to read and edit by hand afterwards, because you can see at a glance which values share a column. If you plan to edit the table after generating it, a padded source is worth having.

The generator runs in your browser, so the table contents stay on your device. That is a minor point for most tables, but it matters when a table contains internal figures, unpublished prices, or draft data you would rather not send to a remote service for a formatting job.

A worked example

Suppose you need a price list for three products, with a column for whether each is in stock. The generated table looks like this:

| Product  | Price | In stock |
| :------- | ----: | :------: |
| Notebook | 19.99 | Yes      |
| Mug      |  9.50 | Yes      |
| Pen set  |  4.00 | No       |

Read the separator row: the first column is left-aligned (:---), the price column is right-aligned (---:), and the stock column is centred (:---:). Rendered, the table shows three products with prices aligned on the right, which makes the numbers easy to compare down the column. You can verify the arithmetic that the table invites: add the three prices and 19.99 + 9.50 = 29.49, plus 4.00 gives 33.49 in total. The table itself does not compute that total — Markdown tables have no formulas — but presenting the numbers in an aligned column makes the mental addition straightforward, which is part of why the alignment choice matters.

Now consider what happens if you type this table by hand and drop a pipe from the second row. The row | Mug 9.50 | Yes | has only two separators instead of three, so the renderer sees two cells where three are expected: the product and price merge into one cell, and every value after it sits in the wrong column. The rendered table looks broken, but the cause is a single missing character in the source, and finding it by eye means counting pipes row by row. A generator never drops that pipe, because it builds each row from the same column count. That is the entire argument for generating tables rather than typing them: the failure mode of hand-typing is silent and common, while the generator's output is structurally consistent by construction.

Editing a generated table is also easier than editing a hand-typed one, provided the source is padded. To add a row, copy an existing body row, change the values, and keep the pipes in their columns. To add a column, add one cell to the header, one dash group to the separator, and one cell to every body row — and count the cells in each row afterwards, because a column added to the header but forgotten in one body row will break that row exactly as a missing pipe does.

Common mistakes

The most common mistake is a row with the wrong number of cells. It happens when a cell value itself contains a pipe character, which the renderer reads as a column separator, splitting one cell into two. If a value must contain a pipe, escape it with a backslash (\|) so the renderer treats it as text. When a rendered table has a row that looks shifted, check that row's cell count first, and look for an unescaped pipe inside a value.

The second mistake is forgetting the separator row. Without the row of dashes, the whole block renders as plain text with pipes visible, not as a table. The separator row is what tells the renderer "this is a table", and it must come immediately after the header, with no blank line between them. If your table renders as raw pipes, the separator row is missing, malformed, or separated from the header by a blank line.

The third mistake is putting block content inside cells that Markdown tables cannot hold. A table cell can contain inline formatting — bold, italic, links, code spans — but it cannot contain a multi-line paragraph, a list, or another table in standard Markdown. Trying to force those in produces broken or surprising output. If a cell needs a list, either summarise it as comma-separated text or restructure the document so the list lives outside the table.

The fourth mistake is making tables too wide. A table with eight or ten columns may render on a desktop screen but becomes unreadable on a phone, where it either shrinks to illegibility or forces horizontal scrolling. If a table keeps growing, ask whether every column earns its place, or whether the data belongs in a different format — a list of sections, a chart, or a downloadable spreadsheet — with a summary table in the document itself.

Honest limitations

A table generator produces Markdown; it does not compute, sort, filter, or validate your data. It will not total a price column, warn you that a value looks wrong, or check that a product name is spelled consistently across rows. Markdown tables themselves have limits: no merged cells, no formulas, no footnotes inside cells in most renderers, and inconsistent support for wide tables on small screens. The generator also cannot guarantee that your table will render identically everywhere, because Markdown table support varies between renderers — most modern renderers support the basic syntax shown here, but older or minimal ones may not. If a table must look identical for every reader, a different format, such as HTML or a PDF, is a safer choice.

Closing

Generate the table, check that every row has the same cell count, use alignment to make numbers comparable, and escape any pipe that belongs inside a value. A table built that way renders correctly the first time and stays easy to edit. To write the surrounding document with a live preview, use the Markdown Editor and Preview, and to prepare tabular data before turning it into a table, use the CSV Viewer and Editor. For working with CSV data more broadly, see CSV Viewer and Editor: Edit Tables in Browser.