SQL to CSV

CSV Output

The CSV will appear here...

How to Convert SQL to CSV Online

Paste your INSERT statements into the left panel, or upload a .sql file
If the dump holds several tables, pick the one you want from the row of table names
Check the preview

the header row comes from the INSERT column list, or from a CREATE TABLE in the same file.
Download the selected table as CSV, or download every table at once as a zip

Common Use Cases

Reading a database backup a colleague sent you without installing the database it came from

Pulling one table out of a large dump so you can open it in a spreadsheet

Turning a seed or fixture file into a CSV you can edit and hand back

Checking what a dump actually contains before you restore it anywhere

Why Use Our SQL to CSV Converter?

Somebody emails you a .sql dump when all you needed was the rows in a spreadsheet. The usual answer is to install a database client, create a database, import the dump, run a SELECT and export the result — a job measured in tens of minutes, for data you wanted to read once. This page skips every step of that. It reads the INSERT statements as text, in your browser, and hands you a CSV per table. Nothing is uploaded and no SQL is executed, so a dump you are not allowed to send to a third party is still one you can read here.

A SQL dump is a text file of statements, not a database. That is the whole reason this page can exist: the rows are already sitting in the file as literal values, and reading them back out needs a parser, not a database engine.

The parser walks the file character by character, tracking whether it is inside a string, a quoted identifier or a comment. That detail matters more than it sounds. A regular expression that strips comments first will happily delete half a row whose text contains a double hyphen, and a splitter that breaks on every semicolon will cut a statement in two the moment a value contains one. Both failures are silent — you get a smaller CSV and no error.

Identifiers arrive in three styles depending on which database wrote the file: double quotes from PostgreSQL, backticks from MySQL, square brackets from SQL Server. All three are unwrapped. Dotted references keep only their last part, because public.users and users are the same table once the rows are in a spreadsheet.

What the page will not do is guess. An INSERT that draws its rows from a SELECT has no literal values in the file, so no honest parser can produce them; those statements are listed under the output by line number instead of being quietly dropped. Custom-format pg_dump archives, COPY BINARY sections and binary blobs are likewise out of scope — they are not text, and pretending otherwise would produce a plausible, wrong CSV.

How it compares

Most online SQL to CSV tools upload your dump to a server to do the work. A database export is usually the most sensitive file anybody will hand you — customer records, email addresses, order history — so uploading it to convert it is a poor trade. This page runs the parser in your browser; the file never leaves the tab.

Some converters take a different route and run the SQL against an in-browser SQLite engine, which means your dump has to be valid SQLite and has to include a CREATE TABLE and a trailing SELECT. A plain mysqldump full of INSERT statements will not load. Reading the statements as text has no such requirement.

If you already have a .db or .sqlite file rather than a dump, the SQLite Browser opens it directly and exports CSV from there. Going the other way, CSV to SQL turns a spreadsheet back into INSERT statements.

SQL to CSV Tips

Column names come from the INSERT column list first, then from a CREATE TABLE earlier in the same file, then from positions — so include the CREATE TABLE if you have it.
NULL becomes an empty cell, never the word null, so a spreadsheet reads it as blank rather than text.
Both escaping styles are handled: the standard doubled quote and MySQL's backslash escapes.
A dump with several tables gives you a zip. Downloading one table alone still works from the picker.
An INSERT ... SELECT carries no literal rows. It is listed under the output rather than guessed at.

Frequently Asked Questions

Does my SQL dump get uploaded anywhere?

Not on this page. The dump is parsed in your browser and the CSV is built there, without sending it to a server, which matters because a database export is usually the most sensitive file you will be asked to open. The REST API and MCP tool are a separate path: a call sends the SQL you include to FindUtils over HTTPS, where it is converted and the result returned. FindUtils does not store it, and logs the request without its content.

Do I need a database installed?

No. Nothing is executed. The rows in an INSERT statement are already literal values in the text, so reading them needs a parser rather than a database engine.

Which dumps does it understand?

Any dump whose rows are written as INSERT statements with literal VALUES: a plain mysqldump, a SQLite .dump, and a pg_dump made with --inserts or --column-inserts. A default pg_dump writes its rows as COPY blocks instead of INSERT statements, and this page does not read COPY blocks, so re-export with --inserts. Custom-format pg_dump archives and binary blobs are not text and are out of scope.

Where do the column names come from?

From the INSERT column list when it has one. Failing that, from a CREATE TABLE for the same table earlier in the file. Failing both, the columns are named column_1, column_2 and so on by position.

What happens to NULL?

It becomes an empty cell. Writing the word null would turn a missing value into the four-character text "null", which a spreadsheet and every later import would treat as data.

What about a comma or an apostrophe inside a value?

Both survive. The parser reads the SQL string literal first, decoding a doubled quote and MySQL's backslash escapes, and the CSV writer then quotes the field if it contains a comma, a quote or a newline.

My dump has several tables. What do I get?

A row of table names appears above the panels with the row count for each. Pick one to preview and download it on its own, or use Download all as .zip to get one CSV per table in a single file.

Why was one of my statements skipped?

Because it had no literal rows to read. An INSERT ... SELECT builds its rows from a query at run time, so the values are simply not in the file. Those statements are listed by line number under the output rather than being dropped silently.

Is there a row limit?

On this page the dump is parsed in your browser, so the limit is the parser's own: it stops at 50,000 rows per table and tells you it did, so a very large dump cannot lock up the tab. Split the file if you need more. Over the REST API and MCP tool, the max_rows argument sets the cap per table, up to 200,000 rows.

Can I use this from a script or an AI client?

Yes. The same parser is available over HTTP and to MCP clients, so an agent can convert a dump without opening this page. The reference pages for both surfaces are linked from the tool.

Can I get JSON instead of a spreadsheet?

Yes. SQL to JSON reads the same INSERT statements with the same parser and returns JSON objects with typed values: NULL becomes null, TRUE and FALSE become booleans and numbers stay numbers. It is the quicker route to API fixtures or mock data.

Run it from code

$ curl -X POST \
  api.findutils.com/api/tools/sql-to-csv/execute \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"sql":"INSERT INTO people (id, name) VALUES (1, '\''Ada'\''), (2, '\''Doe, John'\'');"}'

$ claude mcp add findutils \
  --transport http https://mcp.findutils.com/ \
  --header "Authorization: Bearer YOUR_API_KEY"
# then call findutils:sql_to_csv

Running a tool needs an API key. Keys are not for sale yet: ask for early access. About API keys

The REST API and the MCP tool are a separate path from this page: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

API reference Add to Claude