Build or paste a Markdown table and see it read back cell by cell, with column widths measured in display columns so CJK text, emoji and accents line up, and pipes escaped in the right order
Initializing in your browser…
Markdown editor with a live preview from a real CommonMark 0.31.2 parser, scored 580 of 652 against the specification, plus GitHub tables, task lists and strikethrough, a document outline, and .md and .html export
HTML to Markdown and back, built on a real HTML tree and a CommonMark parser rather than regular expressions, with GitHub tables, a live preview, and a report of everything Markdown could not carry
134 printable paper templates - dot grid, graph, isometric, hex, Cornell notes, handwriting guides, planners, calendars, manuscript paper, tablature, game boards and more. True vector PDF, SVG or PNG at any paper size.
A table of cities where one name is written in Japanese and one price cell holds a pipe character.
Cells
Tokyo in Japanese, Delhi, Sao Paulo, and a cell reading a|b
Markdown
Every line exactly the same width, the pipe written as a backslash and a pipe, and a line underneath saying every cell read back.
Column widths are counted in display columns from Unicode Annex #11, so two CJK characters take four columns rather than two and the source still lines up. The pipe is escaped after the backslash, so a cell ending in one cannot swallow the separator. Then the tool parses what it wrote and compares every cell with what you typed.
Build a Markdown table in a visual grid, or paste one in and edit it. The tool then reads its own output back and tells you whether every cell and every alignment came through, and in the aligned layout it checks that every line is exactly the same width in a monospace font.
Writing a Markdown table by hand is fiddly for two reasons, and this tool exists to remove both.
The first is escaping. A pipe is the column separator, so a pipe inside a cell has to be written as a backslash and a pipe, and a backslash has to be escaped before the pipe is, or a cell ending in a backslash escapes the separator that follows it and two cells become one. Both are done here, in that order. A line break cannot appear in a cell at all, because a table row is one line, so what a break becomes is a choice you make (a break tag, a space, or nothing) and the page says which was applied.
The second is alignment, and it is where a generator is most likely to be quietly wrong. Padding a column so the source lines up requires knowing how many COLUMNS a string occupies, which is not how many characters it has. Two CJK characters are two code units and occupy four columns. An emoji is two code units, one character to a reader, and two columns. A letter with a combining accent is two code units, one character, and one column. The widths here come from Unicode Standard Annex #11, from a table generated out of the Unicode Character Database and checked against it for every one of the 1,112,064 code points, so a table holding Japanese, an emoji or an accent lines up exactly like one holding ASCII.
Three layouts are offered and all three produce the same rendered table: aligned (padded so the source lines up), one space around each cell, and no spaces at all. Outer pipes are optional, because GFM accepts a table without them.
You can also paste a table IN. A Markdown table, a CSV or a TSV are all read, and which one it is is worked out from the text rather than asked for. The Markdown reader is this project's own CommonMark parser with its GFM table extension, so what it accepts is what it can write back; the CSV reader follows RFC 4180, so a quoted field holding a comma or a line break comes through intact.
What the tool does not do is pretend the format carries more than it does. Markdown strips the whitespace around a cell, so leading and trailing spaces cannot survive, and the page says so when your cells have them rather than letting you find out later.
Create comparison tables and feature matrices whose source lines up in an editor, so the next person to edit it can see the columns.
Paste tab-separated data straight out of a spreadsheet, or a CSV with quoted fields, and edit it as a grid before copying the Markdown.
Paste an existing Markdown table in, change a cell or an alignment, and take it back out in the layout you want.
Japanese, Chinese, Korean, emoji and accented text all pad correctly, which padding by character count does not manage.
It is escaped as a backslash and a pipe, which is what GFM section 4.10 specifies, and the backslash in your cell is escaped first so the two cannot interfere. The tool then reads the table back and confirms your cell came through.
Not as a line break: a Markdown table row is one line. You choose what a break becomes, a break tag (which GitHub renders as a line break, though it is raw HTML), a space, or nothing, and the page tells you when it applied that choice.
Because the padding counts display columns rather than characters. A CJK character occupies two columns in a monospace font and one code unit in memory; measuring the wrong one leaves the column two short per character.
Yes. Copy cells and paste them into the import box; tab-separated data is recognised, as is a CSV and an existing Markdown table.
No. All three produce the same table once rendered; they differ only in how readable the source is. Aligned is the longest and the easiest to edit by hand.
There is no hard limit, but a very large table is unwieldy as Markdown. For data-heavy tables, link to a CSV instead.
Your text is processed locally in the browser. Nothing you paste or open is transmitted or logged.