SQL to Markdown Table Converter
Show the rows instead of describing them. Paste your INSERT statements and get a Markdown table you can drop into a pull request, a runbook or an incident write-up.
To convert SQL to a Markdown table, paste your INSERT statements above. Each row becomes a table row keyed by the column names from the INSERT or from a matching CREATE TABLE, numeric columns are right-aligned so the digits line up, pipes inside values are escaped, and line breaks become <br> so the table survives. Copy the text straight into GitHub.
Want to trim the columns first? Open the app
Rows in a review are worth a paragraph of explanation
The reason this conversion exists is code review. Somebody asks "what does the seed data actually look like?" and the honest answer is eleven INSERT statements that nobody is going to read in a diff. Five rows in a table answers the question in one glance.
The same is true of an incident write-up, where the useful artefact is the six rows that were wrong, and of a runbook, where the useful artefact is the lookup table somebody keeps having to query for.
Markdown is the right container for all three because it renders everywhere those documents live and it survives being copied between them as plain text.
Worked example
A fragment of seed data:
INSERT INTO regions (region_code, region_name, opened_on, active) VALUES
('01', 'North Coast', '2019-03-04', TRUE),
('02', 'Lakeside', '2020-07-19', TRUE),
('03', 'High Plains', '2021-11-30', FALSE);And the Markdown, exactly as it comes out:
| region_code | region_name | opened_on | active |
| --- | --- | --- | --- |
| 01 | North Coast | 2019-03-04 | true |
| 02 | Lakeside | 2020-07-19 | true |
| 03 | High Plains | 2021-11-30 | false |Note that region_code is left-aligned even though it looks like a number. The column was typed once and came back as text, because 01 is not the number one, and aligning it right would be a small lie about what the data is. A competing converter on this term right-aligns exactly this column after typing it as text one pane earlier.
The three things that break a Markdown table
A pipe inside a value ends the cell. A note that reads canary 10% | full rollout silently turns one row into a row with an extra column, and the renderer either drops the tail or draws a broken table. Every pipe in your data is escaped as \|, so the cell survives.
A backslash is escaped first, before the pipes, because a value ending in a backslash would otherwise consume the escape on the pipe after it. That ordering is the sort of thing that only shows up on the one row that has it.
A newline inside a value ends the row, and Markdown has no line continuation. Those become <br>, which GitHub renders as a line break and every other reader shows as literal text. Both are better than a table that falls apart. A competing converter deletes the newline and joins the two lines with a space, which reads fine and quietly changes your data.
Alignment, and when to override it
Auto is the default and means one thing: a column whose every value is a real number gets a right-aligned marker, so the digits and decimal points line up down the column and you can see at a glance which figure is the big one. Everything else is left-aligned.
The three explicit modes exist for the cases where the data does not decide well. All centered suits a short status column. All right suits a table that is entirely figures. All left suits a table you are going to keep editing by hand, because the alignment markers are the fiddliest part of a Markdown table to maintain.
Columns are not padded to a common width. It costs a lot of bytes on a wide table, no renderer cares, and it makes the diff unreadable the next time somebody changes one value.
Size, and when a table is the wrong answer
Above about ten thousand rows a Markdown table stops being a document and becomes a scrolling wall. GitHub renders it, slowly, and nobody reads past the first screen. The conversion still runs, because it is your data and your call, but a note appears saying what you are about to paste.
If the goal is for someone to look at the numbers rather than to read a document, an Excel export or a link to the dashboard is almost always the better artefact, and both are one click away from here.
Frequently Asked Questions
Does it escape pipes inside my values?
Yes, every one, and backslashes are escaped first so a value ending in one cannot eat the escape on the pipe that follows. An unescaped pipe is the single most common way a generated Markdown table arrives broken in a review.
What happens to a line break inside a value?
It becomes a <br>. Markdown has no way to continue a table row onto a second line, so the choice is between that and losing the break. GitHub renders it properly; other readers show the tag as text, which is still better than two lines silently becoming one.
Why is my code column left-aligned when it looks numeric?
Because it was typed as text, usually because of a leading zero. Right-aligning it would present it as a quantity when it is an identifier. Auto alignment follows the type the column actually has, not the shape of the characters.
Can I center everything?
Yes. Alignment offers auto, all left, all centered and all right. Auto is the default and right-aligns numeric columns only, which is the setting that makes a table of figures readable.
Are the columns padded so the source lines up?
No. Padding costs a lot of characters on a wide table, no Markdown renderer takes any notice of it, and it makes the next diff on that file unreadable. The source is compact and the rendered table is identical either way.
How many rows is too many?
Past about ten thousand you get a note. Nothing is blocked, but a Markdown table that long renders slowly on GitHub and nobody scrolls it. For a table that size the point is usually to let someone look at the numbers, which a spreadsheet or a dashboard does better.
Paste the rows into the review
Escaped pipes, kept line breaks, numeric columns aligned. Copy and go.
Back to the converter