SQL to CSV Converter — Online & Private

How SQL to CSV conversion works

SQL to CSV Converter runs SQL INSERT statements through a deterministic, fully client-side pipeline and produces CSV output in a single pass — no round-trips, no queues, no waiting on someone else's server. Paste INSERT INTO ... VALUES statements into the input pane — multi-row tuples and multiple statements are merged. Press Run Conversion (or just pause typing — the studio parses as you go), and the generated output appears on the right with line numbers, syntax highlighting, and one-click copy or download.

INSERT statement parsing — literal values only

The parser reads INSERT INTO ... VALUES statements the way an import reviewer would: it extracts the column list (quoted or unquoted identifiers), every value tuple in multi-row VALUES lists, and every statement in the paste. String literals honor SQL's doubled-quote escaping (O''Brien becomes O'Brien), NULL becomes an empty cell, TRUE/FALSE become native booleans, and numeric literals keep their exact text. Statements without a column list infer positional names (column_1, column_2) from the row width.

The deliberate boundary: values must be literals. SELECT statements, placeholders/parameter markers, and subqueries have no tabular value to extract, and the parser says so plainly rather than guessing. Output from this site's own CSV/Excel-to-SQL converters round-trips perfectly — the CREATE TABLE block is skipped and the INSERT tuples parse back to the original rows, making the pair a lossless JSON-to-SQL-to-CSV bridge when you need one.

SQL to CSV: turning INSERT dumps back into data

Every INSERT dump carries a table hiding inside it: the column list names the fields, each value tuple is a row, and multi-row VALUES plus repeated statements are just one table sharded across statements. The parser reconstructs exactly that — merging every tuple it finds, un-escaping SQL string literals ('' back to '), mapping NULL to an empty cell, and passing TRUE/FALSE and numerics through as their natural values. Column lists may be quoted any way your engine likes: double quotes, backticks, brackets, or bare.

The reverse trip composes: output from this site's CSV/Excel-to-SQL converters parses back to the original rows, making JSON-to-SQL-to-CSV a lossless round-trip when you need to move data through a SQL-shaped checkpoint. The boundary is honest and stated: values must be literals — SELECT statements and placeholder parameters contain no rows to extract, and the parser rejects them with a specific message rather than a partial guess.

RFC 4180 quoting and delimiter control

The generated CSV follows RFC 4180 exactly: fields containing the delimiter, a double quote, a line break, or leading/trailing whitespace are wrapped in quotes with internal quotes doubled — the escaping every spreadsheet, database loader, and pandas read_csv honors identically. Fields that need no quoting are emitted bare, so a clean table converts to visually clean CSV rather than a wall of unnecessary quotation marks.

The delimiter is a first-class option: comma (the default), semicolon (European spreadsheet exports), tab (TSV for shell pipelines and Excel paste), and pipe (legacy database dumps). Switching delimiters re-quotes on the fly — a field that was safe bare next to a comma gets quoted the moment you pick semicolons — so the output is always valid for the dialect you selected, never just a find-and-replace.

Private by architecture: your data never leaves the browser

Every stage of this conversion — parsing, type inference, and output generation — executes locally inside your browser's JavaScript engine. The input is never transmitted, logged, or stored: there is no upload endpoint, no queue, no telemetry, and no account to create. Files larger than 1MB are handed to a background Web Worker so the interface keeps animating at 60fps even on hundred-thousand-row imports, and the page keeps working offline once loaded because it is a fully static export.

That architecture makes the tool safe for the exports you would never paste into a random website: customer PII, financial line items, internal Salesforce extracts, and unreleased product data. Paste it, convert it, copy or download the result — and the bytes never moved from your machine.

Limits and practical tips

Inputs are capped at 15MB per file or paste — hundreds of thousands of rows in practice — purely as a browser-safety guard rather than a server policy, since there is no server involved at all. Processing is single-pass and deterministic: the same input with the same options always produces byte-identical output, which makes the generator safe to keep in CI pipelines and documentation. Pick the delimiter your consumer expects before copying — switching it later means re-checking which fields got quoted.

How do I convert SQL INSERT statements to CSV?

Paste the INSERT INTO ... VALUES statements — a single multi-row statement, several statements, or a whole dump fragment — and press Run Conversion. The column list becomes the header, every value tuple becomes a row, and the CSV appears with copy and download buttons. No database connection is involved at any point.

Which SQL dialect does the parser accept?

The value syntax is ANSI: single-quoted strings with doubled-quote escapes, NULL, TRUE/FALSE, and numeric literals — which MySQL, PostgreSQL, SQLite, and SQL Server dumps all emit. Column lists accept double-quoted, backticked, bracketed, and bare identifiers. SELECT queries and placeholder parameters are out of scope by design: there are no literal values in them to extract.

How are NULLs and empty strings handled?

NULL becomes an empty CSV cell — the convention spreadsheet consumers expect for missing values. Empty SQL strings ('') also produce empty cells, matching how CSV itself cannot distinguish the two; if the distinction matters downstream, keep it in the SQL layer where it exists. TRUE and FALSE convert to true and false text.

Can I convert a full database dump?

Paste the INSERT fragment of it. mysqldump-style dumps interleave CREATE TABLE, LOCK TABLES, and comments, which the parser skips harmlessly — but all statements in one paste must share the same column list (or omit it consistently), because the output is one table. For multi-table dumps, split by table and convert each fragment separately.

Is my SQL uploaded anywhere?

No. Parsing happens entirely in your browser against the pasted text — no server, no database connection, no logging. That is the point: production data inserts stay on your machine whether they contain customer records or internal metrics.

Does the converter run a database connection?

Never — there is no database, no driver, and no execution of any kind. The parser reads the INSERT text you paste as text, extracting column lists and literal value tuples exactly as written. That is also why it is safe for production dumps: the data never leaves your machine, and no statement can execute as a side effect of conversion.

What about INSERTs generated with placeholders or SELECT ... INSERTs?

Those are out of scope by design: statements like INSERT ... SELECT or INSERT with ? placeholders contain no literal rows to extract, and the parser rejects them with a specific message instead of producing a misleading partial table. Export literal INSERTs (mysqldump, pg_dump --inserts, or this site's own SQL generator) and the parser handles them natively.