Markdown Table Formatter

Why Markdown tables drift out of alignment

A Markdown table is just text: a header row, a delimiter row of dashes, and body rows, all separated by the pipe character |. The GitHub Flavored Markdown (GFM) spec, which defines the table syntax GitHub renders, trims the spaces between pipes and cell content, so whether the columns line up in the source makes no difference to the rendered table. That tolerance is convenient when you write, but it means tables decay fast. A model emits a table with no padding. A teammate edits one cell and the columns shift. The rendered output still works, but the source becomes painful to read in a pull request or a plain-text diff.

This formatter restores that source-level readability. It parses every row, measures the widest cell in each column, and pads every cell to that width so the pipes form clean vertical lines. It rebuilds the delimiter row with the alignment markers GFM defines: a colon on the left of the dashes (:---) for left, colons on both sides (:---:) for center, and a colon on the right (---:) for right. The alignment your table already has is kept unless you choose to override it.

Widths are measured in columns, not characters

Lining up pipes means counting how wide each cell looks in a monospace editor, and that is not the same as how many characters it holds. Chinese, Japanese and Korean characters, and most emoji, take two columns; an accent added as a combining mark takes none. The formatter uses Unicode's East Asian Width property to count Wide and Fullwidth characters as two, so a column holding 李小龍 is padded to match one holding Ada Lovelace. That lines up in editors whose font draws those characters at exactly double width, which most monospace setups do; if yours does not, the rendered table is unaffected.

The rules it follows

GFM's table section settles the edge cases. A literal pipe inside a cell is written \|, even inside backticks, and the formatter never splits a cell there. The header row and the delimiter row must have the same number of cells or no table is recognised, so a missing delimiter row is added. A body row with too few cells gets empty ones. A row with too many has its extra cells dropped when GFM renders it, so the formatter adds empty header columns instead, which keeps the data visible, and tells you it did. CSV is read by RFC 4180's rules, so "Smith, John" stays one cell and doubled quotes become one; a line break inside a cell becomes <br>, because a table row must fit on one line.

Cleaning model and spreadsheet output

Two sources produce the messiest tables. Chat models emit compact tables with no padding, sometimes with a missing outer pipe or an uneven cell count. Spreadsheets put cells on the clipboard as tab-separated values with no pipes at all. Paste either, pick the input format, and the same engine produces a properly piped, padded table. Switching the output to CSV goes the other way, unescaping \| and <br>, and formatting a table it has already formatted changes nothing, so you can run it on your own output safely. Everything runs in your browser; nothing you paste is uploaded.