Convert SQL to CSV

Usually you are not really asking for SQL to CSV

You have been handed a .sql file. Perhaps it came out of a hosting control panel labeled backup, perhaps a developer sent it, perhaps it fell out of a WordPress export. It will not open in anything useful, it is far too long to read, and the actual question is simpler than conversion: what is in this thing?

So that is what happens first. Drop the file and every table in it is listed by name with its row count and its columns — before any choice about output format. Nine times out of ten that list is the answer on its own, because the moment you can see wp_users sitting next to wp_postmeta, you know which one you wanted. Exporting the columns you tick is just what you do next.

SQL and CSV, in brief

SQL

Full name	Structured Query Language
Extension	.sql
Format type	Plain text statements, not a data format
MIME type	application/sql

CSV

Full name	Comma-Separated Values
Extension	.csv
Format type	Plain text table, one record per line
MIME type	text/csv

Pulling three columns out of one table

This is the request underneath most visits: get the names, email addresses and phone numbers out of the contact form table and into something openable. It is not a separate feature here and it deliberately does not have a button of its own. Once the table is on screen with its column names, untick the fifteen columns you do not care about and the file contains three.

A spreadsheet is only one of the places that selection can land. When the rows are headed for code rather than for a person — seeding a test fixture, feeding an import script — SQL to JSON writes the same ticked columns as records instead, and keeps nulls distinguishable from empty strings, which a CSV cannot do at all.

That framing matters because the alternative — a tool that offers to extract contacts — would have to guess which columns those are, and it would guess from column names invented by whoever wrote the plugin. Showing you the table and letting you point is both simpler and more likely to be right.

If the addresses are scattered through the file rather than sitting in a column of their own — in a serialized settings blob, say, or a comments table — the email extractor reads the same dump and pulls out every address in it, also without uploading anything.

Why the file is tokenized instead of pattern-matched

The tempting shortcut is a regular expression along the lines of INSERT INTO .+ VALUES (.+);. It works on the example you tested it with and fails on the first real dump, silently, in four separate ways.

A semicolon inside a value ends the statement early and half the row vanishes. A bracket inside a value throws off the bracket counting. A comma inside a value splits one cell into two, shifting every column after it. And an apostrophe escaped as \' — legal in MySQL, not in PostgreSQL — ends the string for any reader that does not know which engine wrote the file. Every one of those produces output that looks fine at a glance. Here the file goes through a real tokenizer first, so quoting, comments and escapes are already resolved before a single row is read, and the dialect is named on screen with the evidence that suggested it.

What a mysqldump throws at a reader

It is the most common kind of file people bring, and it is full of things that are not SQL as anyone writes it by hand. Identifiers in backticks. ENGINE=InnoDB trailing the table definition. Comments in the form /*!40101 … that are comments to every engine except MySQL, which executes them. And INSERT statements with no column list at all, because that is the default — so the column names have to be recovered from the CREATE TABLE hundreds of lines earlier.

Index definitions inside that CREATE TABLE are skipped rather than counted. Miss that and your CSV arrives with two extra columns called PRIMARY and KEY, which is exactly the sort of nonsense that makes people give up on the file and email it to somebody instead.

All of that concerns the data. If what you actually need is to read the statements — to work out what a migration does before running it, or why a schema looks the way it does — the extraction here will not help, because it throws the structure away on purpose. The SQL formatter is the other half of that: it leaves every statement intact and re-indents it so the nesting becomes visible.

Getting it to open cleanly in Excel

Keep the byte order mark, which is on by default. Without it Excel reads the file in its local code page and every accented character arrives mangled — the single most common complaint about CSV exports anywhere. If your Excel is a Swedish, German or French install, switch the separator to a semicolon too: those versions expect it, and a comma-separated file lands entirely in column A.

One thing a CSV cannot fix is Excel's habit of reinterpreting values on import. Long IDs become scientific notation and leading zeros disappear, whatever the encoding says, because that happens after the file is read. If your table has either, take the workbook export instead — every cell there is typed, so nothing gets reinterpreted.

And if the spreadsheet is a stop rather than a destination — fix a few hundred rows by hand, then put them back — CSV to SQL writes the INSERT statements for the return journey. It is the harder half of the round trip, because a CSV has thrown away every type this file declared and they have to be inferred again from the characters.

A dump is the most sensitive file you own

Not a document. Every row of every table: the customers, the addresses, the order history, the password hashes, the API keys somebody stored in a settings table. There is no upload endpoint here, and you can verify that in the network panel while you drop the file. Nothing is refused for its size either, and the reading runs off the main thread so a large backup does not lock up the page while it is parsed.