Nobody reads a dump in a README
An INSERT line already carries a miniature spreadsheet: table name, column list, one tuple per row. Turning those tuples into an HTML table is the fastest way to make seed data legible in internal docs, a pull request description or a support ticket. The hard part is not the tags. The hard part is keeping commas inside quoted strings from splitting a row in half, then writing every cell value back out without letting a stray angle bracket break the page.
Limitation up front: only INSERT and REPLACE statements with literal value tuples are read. A SELECT export, an INSERT ... SELECT, or a CREATE TABLE block is skipped entirely. If your file is mostly DDL, run the SQL formatter first so you see what is left, then paste the INSERT sections here.
How a statement maps to markup
The parser walks the text character by character inside the VALUES section, the same approach the SQL to CSV converter uses. Quoted strings, nested parentheses inside a function call, and doubled apostrophes all stay inside one field. Once the tuples are split, the mapping is mechanical.
| Part of the INSERT | Becomes in HTML |
|---|---|
Table name after INTO | A heading above each <table>, or a data-table attribute on the wrapper |
| Column list in parentheses | <th> cells inside <thead> |
| Each value tuple | One <tr> in <tbody> |
NULL | An empty <td> |
Text with <, & or quotes | Escaped entities so the browser prints the character instead of parsing it |
INSERT INTO products (sku, label, price) VALUES
('KB-88', 'Mech keyboard', 189.00),('MS-12', '27" mouse pad', NULL);<table><thead><tr><th>sku</th><th>label</th><th>price</th></tr></thead><tbody><tr><td>KB-88</td><td>Mech keyboard</td><td>189.00</td></tr><tr><td>MS-12</td><td>27" mouse pad</td><td></td></tr></tbody></table>Row two needed two rewrites. The inch mark became " inside the cell. The NULL became an empty cell instead of the four letters NULL, because HTML has no native missing value and an empty cell reads cleaner in a doc than a misleading word.
Full page versus a fragment you paste elsewhere
Two output modes sit above the editors, and they target different destinations.
- Full page wraps every table inside a complete HTML document with a charset meta tag, a viewport line and a small embedded stylesheet. Open the downloaded file in a browser and the grid is already readable. Hand the file to someone who does not have your repo checked out.
- Fragment only drops the outer document and leaves the table blocks. Paste the result into a Confluence page, a static site generator, or a CMS field that already owns the surrounding HTML. Nothing to strip out first.
The Styled preset adds borders, zebra rows and a coloured table title bar. Bare markup emits plain <table> tags with no class names and no CSS, which is what you want when your site already ships a table component and you only need the rows.
Several tables in one paste
Real dumps interleave users, orders and line items. Each distinct table name becomes its own HTML block. The picker at the top right switches the preview to one table while Include every table stays checked, which is what copy and download use. Turn the checkbox off to export only the table you are previewing, handy when a ten-table dump needs one grid in a ticket.
Rows are grouped by table name, not by file position, so a dump that returns to the users table halfway down still lands in one block. Schema prefixes such as public.orders are kept in the name so two schemas with an orders table do not merge.
Escaping is not optional
Seed data often contains user-supplied text. A product description with <script> in it is still data, but an unescaped cell would run as markup in a browser. Every value is passed through an HTML entity encoder before output. Apostrophes, ampersands and angle brackets become entities. The page you generate is safe to open locally.
That encoding is one-directional. Pasting the HTML into a Markdown file that allows raw HTML still executes nothing as long as the host respects standard escaping. Pasting into a WYSIWYG editor that re-interprets entities is outside what this tool controls.
When CSV or XML fits better
HTML tables are for human eyes in a browser or a doc system. They are a poor interchange format.
- Feeding rows into Excel or a script wants CSV, not a table with presentation markup wrapped around it.
- An API or a config loader that expects elements, not cells, wants XML or YAML from the same INSERT syntax.
- Building the schema before you have rows belongs in the SQL table generator, which outputs CREATE TABLE instead of reading INSERT.
What never becomes a row
- No expression evaluation.
NOW(),UUID()and1 + 1arrive as literal text, because nothing here connects to the database that would have evaluated them. - No hex or binary decoding. A blob written as
0x89504E47stays as that string. - No
INSERT ... SELECT. Those statements carry a query, not literal tuples. - Large dumps slow the tab. Parsing runs on the main thread in your browser. A few megabytes is fine. A production-sized dump belongs on the server with a proper export tool.
- Email clients ignore most table CSS. Styled output is for browsers and doc systems. Inline styles for mail need a different pipeline.
Nothing you paste is uploaded. Conversion, preview, copy and download all run in JavaScript on this page, so a dump with customer rows never leaves your machine.
