Markdown Table Generator

Markdown table generator: build a table in a grid, copy the markdown

Hand-writing a markdown table is a chore for exactly one reason: the pipes. The syntax itself takes a minute to learn, but keeping every | lined up while you add a column, rename a header or lengthen one cell is tedious in a way that produces mistakes. This tool removes that step. You fill in a spreadsheet-style grid, pick an alignment per column from a dropdown, and the generated markdown appears below — already padded so the source is readable — with a copy button.

Everything runs in your browser. The tool makes no network requests; the text you type is never sent anywhere, which makes it usable for internal documentation and unreleased content without a second thought.

Using the grid

The editor opens with three columns and two rows filled in as an example, so you can see the output shape immediately. Replace the contents and adjust the shape with the four toolbar buttons:

• + Column appends a new column, named Column N, with left alignment and an empty cell in every row.
• − Column removes the last column. It stops at one column.
• + Row appends an empty row matching the current column count.
• − Row removes the last row. It stops at one row.

Row and column removal always take from the end, so build outward rather than trying to delete from the middle. Within a row, Tab moves along the cells in order, which is the fastest way to type a table you already have in your head.

Two outputs update as you type. A rendered HTML preview shows what the table will actually look like, including the alignment you chose. Below it, the markdown source sits in a read-only box with a copy button. There is no save step and no generate button — the markdown is always current.

Column alignment, and what the separator row is for

The second line of a markdown table — the one made of dashes — is not decoration. It is the row that tells the parser “this is a table”. GitHub and every other GitHub-Flavored-Markdown implementation require it. A block of pipe-separated lines without that separator row is rendered as ordinary paragraph text with visible pipes in it, and this is far and away the most common reason a table “does not work” when hand-written.

The separator row also carries per-column alignment, encoded by where you put a colon:

Each column’s dropdown sets its own marker, so a table can mix all three. The number of dashes is irrelevant to the parser — a minimum of three is the convention, and this tool pads to at least three or to the width of the widest cell, whichever is larger. Alignment applies to the entire column including the header, and there is no way to align an individual cell differently.

A worked example

Three columns, aligned left, centre and right, with two rows of data, produce exactly this:

| Name | Role | Location |
| ------------ | :----------: | ----------: |
| Ada Lovelace | Engineer | London |
| Alan Turing | Researcher | Manchester |

Each column is padded to its widest value — twelve characters for Ada Lovelace, ten for Researcher and Manchester — so the source is legible in a plain editor and stays legible in a code review diff.

One thing to notice in that output: the separator row runs slightly wider than the rows around it wherever alignment colons were added, because the colon is appended to a full-width run of dashes. That is purely cosmetic in the source. Parsers ignore separator width entirely and the rendered table is unaffected, so there is nothing to fix — but it is worth knowing so you do not go hunting for a bug that does not exist.

Escaping pipes, and other cell content that bites

The pipe is the column delimiter, so a literal pipe inside a cell would split it in two. It has to be backslash-escaped as \|. This tool does that for you as you type — you enter the character you want and the escaping happens in the output. The same applies to backslashes, which are doubled so they survive markdown’s own escape processing.

So a cell containing -a | -A and a cell containing a Windows path come out as:

| Flag | Effect |
| --------- | ----------------- |
| -a \| -A | Either form works |
| C:\\Users | Windows path |

Both render as the literal text you typed. This matters more than it sounds if you are documenting shell commands, regular expressions or CLI flag alternatives, where pipes and backslashes are everywhere and a single unescaped one silently mangles a row.

Line breaks get the same treatment. A markdown table row must occupy exactly one line — a newline inside a cell ends the row as far as the parser is concerned. Where you have entered a line break, the tool writes <br> instead, which is the standard workaround and renders as a break on GitHub and most static-site generators. Keep in mind that it is raw HTML, so any renderer configured to strip HTML will show the tag literally or drop it.

What markdown tables cannot do

This is worth stating up front so you do not spend an hour looking for syntax that does not exist:

• No merged cells. There is no colspan and no rowspan in markdown tables. If your design needs a header spanning two columns, markdown is the wrong format — write the table as raw HTML instead, which most markdown renderers will pass through.
• No nested tables. A cell cannot contain another table.
• No block content in cells. No lists, no headings, no fenced code blocks, no multi-paragraph cells. Inline formatting does work: bold, italic, inline code spans and links are all fine inside a cell.
• No column widths. Rendering width is decided by the renderer’s CSS, not by your source. Padding the source affects readability of the markdown only.
• No captions or footnotes as part of the table. Put them in the paragraph above or below.
• Every row must have the same column count. A short row leaves trailing cells empty; a long one has its extra cells dropped. The grid here enforces a rectangle for you, which removes an entire class of mistake.

Bringing in data you already have

Be aware of one limitation before you start: this tool has no bulk import. There is no field to paste a CSV block or a copied spreadsheet range into and have it split across cells. You size the grid with the row and column buttons and fill cells individually, tabbing along each row.

That makes it a good fit for tables you are composing now — a comparison matrix, an options table for a README, a schema description, a status summary in a pull request — and a poor fit for converting a hundred rows of existing data, which is better handled by a script or by whatever your source application exports. For a moderate table where you have the values in front of you, cell-by-cell entry is quick and you get correct escaping and alignment for free.

Where the output works

The generated syntax is GitHub-Flavored Markdown, which is the de facto standard for tables. It renders in GitHub issues, pull requests, comments, READMEs and wikis; in GitLab; and in the common static-site generators and documentation tools that build on GFM or CommonMark table extensions.

Where it may not render is in strict original-flavour markdown implementations. Tables were never part of the original markdown specification — they are an extension — so a minimal parser with tables disabled will show your pipes as literal text. If a table fails to render somewhere, the separator row and the renderer’s table support are the two things to check, in that order. If you want to sanity-check a whole document rather than one table, our markdown preview tool renders arbitrary markdown.

Practical notes

• Blank lines matter. A table needs a blank line before it in most renderers. Butting it directly against a preceding paragraph is a common cause of a table that will not render.
• Leading and trailing pipes are optional in GFM, but including them — as this tool does — makes the source far easier to read and to diff.
• Empty cells are fine. Leave a cell blank and it renders as an empty cell. There is no placeholder required, though a dash or n/a often reads better.
• Right-align numeric columns. Decimal points line up and the column becomes scannable. It is the one alignment choice that reliably improves comprehension.
• Keep header text short. Column padding follows the widest cell, so a long header inflates the whole column in the source and pushes the line past a comfortable width in a diff.

Common questions

Why is my table showing as a line of text with pipes in it? Almost always the separator row. It must be the second line, it must contain at least one run of dashes per column, and the number of columns in it must match the header row. The other frequent cause is a missing blank line between the table and the paragraph above it.

Can I put a bullet list inside a cell? Not as a real list. The usual workaround is to separate items with <br> and a bullet character, which this tool will produce for you from a line break in a cell. If the content genuinely needs block-level structure, the table wants to be raw HTML instead.

How do I get a header that spans two columns? You cannot, in markdown. Merged cells are outside the syntax entirely. Either split the table in two with a heading above each half, or write it as HTML.

Does the padding in the output matter? Only to humans. Renderers strip it. It exists so that the markdown source is readable and so that changing one cell produces a small, comprehensible diff rather than a reflowed block.

Will the alignment work everywhere? Alignment colons are part of the GFM table extension, so they work anywhere tables themselves work. A renderer that supports tables will honour them; one that does not support tables will not render the table at all, so alignment is never the thing that fails on its own.

Is my data uploaded? No. The generator is entirely client-side and makes no network calls — the grid, the preview and the markdown output are all produced in the page.