ConvertCSV

Converter tool

SQL to CSV Converter

Convert SQL INSERT data into CSV

Preview

Output Preview

No output yet. Upload or paste input and convert.

SQL to CSV Converter

Database seed files and migration scripts often contain INSERT statements packed with row data that is awkward to review in raw SQL. This free SQL to CSV converter extracts column names and VALUES tuples from standard INSERT INTO statements and lays them out as spreadsheet rows — useful for reviewing seeds, sharing dump excerpts, or preparing test fixtures without a database connection.

Paste INSERT statements from pg_dump, mysqldump, or hand-written seeds, or upload a .sql excerpt. The tool parses column lists and value tuples in your browser, strips string quotes, unescapes doubled apostrophes, and builds RFC-style CSV. Your SQL text is not uploaded to a server as part of the conversion.

Below you will find which INSERT shapes are supported, how multi-statement dumps are merged, what happens with functions and NULLs, Excel pitfalls after download, and a full troubleshooting and FAQ section for real dump-to-spreadsheet workflows. Treat the result as a review extract: great for eyeballing seeds, not a substitute for running SQL against a live database when you need computed values.

Key features

  • Parses standard INSERT INTO ... VALUES (...) syntax without requiring a separate schema file.
  • Combines multiple INSERT statements for the same table into a single consolidated CSV.
  • Strips surrounding quotes from string literals automatically so cell values are clean plain text.
  • Leaves numeric literals as plain numbers in the output.
  • Works directly from a pasted pg_dump, mysqldump, or hand-written seed file excerpt.
  • Runs entirely in the browser so SQL content is not sent to a server for conversion.
  • Respects commas inside quoted string literals when splitting VALUES tuples.

About the SQL INSERT statements to CSV format

The parser recognizes standard INSERT INTO table (col1, col2, ...) VALUES (...) statements. Column names come from the INSERT header; each VALUES tuple becomes one CSV row. String literals lose their surrounding single quotes; doubled quotes ('') become a single apostrophe in the cell.

Multiple INSERT statements for the same table are combined into one CSV so dump files that batch rows across several statements still produce a single sheet. Numeric literals are copied through as plain text numbers. Expressions that are not simple literals (NOW(), UUID(), subqueries) appear as the literal SQL text in the cell because nothing is executed.

Statements without an explicit column list, or INSERT ... SELECT forms, are not a good fit — there is no reliable header row to derive CSV columns from. Prefer dumps that include the column list in each INSERT, or add the column list before converting.

How it works

The parser scans the pasted text for INSERT INTO tablename (col1, col2, ...) VALUES (...) patterns, using the column list from the statement header to name the CSV columns.

Each VALUES tuple is split on commas while respecting nested quotes, so a comma inside a quoted string literal does not break the column count. String literals have their surrounding single quotes stripped and any doubled quotes ('') unescaped back to a single apostrophe; numeric literals are copied through as-is.

If multiple INSERT statements target the same table, their rows are appended into one CSV rather than producing separate files. The result is escaped for spreadsheet use and ready to copy or download.

Common use cases

  • Reviewing a database seed file before running it against a staging environment.
  • Extracting row data from a pg_dump or mysqldump INSERT export for spreadsheet analysis.
  • Sharing sample database records with a teammate who does not have database access.
  • Converting SQL test fixtures into CSV for a data pipeline prototype.
  • Diffing two seed versions by converting both to CSV and comparing in Sheets.
  • Auditing migration INSERT batches for missing columns or obvious bad literals before apply.

How to use this tool

  1. Paste one or more INSERT INTO statements for the same table, or upload a .sql file containing them.
  2. Remove unrelated DDL if the file is a full dump — keep the INSERT blocks you care about.
  3. Review the preview to confirm headers match the column list and string values were unquoted correctly.
  4. Check a few rows with commas or apostrophes inside strings.
  5. Copy or download the CSV for spreadsheet review, sharing, or a downstream import.

Example

Input SQL

INSERT INTO products (id, name, price) VALUES
  (101, 'Widget', 9.99),
  (102, 'Gadget', 14.50);

Output CSV

id,name,price
101,Widget,9.99
102,Gadget,14.50

Tips for best results

  • Paste only INSERT statements — remove CREATE TABLE, ALTER, and other DDL for cleaner results.
  • If your dump uses multiple tables, convert each table’s INSERT block separately.
  • Confirm string literals with embedded commas are properly single-quoted in the source SQL.
  • Prefer statements that include an explicit column list so CSV headers stay meaningful.
  • Spot-check apostrophes (O''Brien style escaping) after conversion.
  • Keep the original .sql until row counts and a few sample cells look right in the preview.
  • For huge dumps, convert a table excerpt first, then batch the rest.

Common errors and how to fix them

The output is empty even though the pasted SQL looks like a valid INSERT.
Check that the statement follows the standard INSERT INTO table (columns) VALUES (...) shape — statements using INSERT ... SELECT or without an explicit column list are not supported, since there is no header row to derive column names from.
A value like NOW() or UUID() shows up literally as text in a cell instead of a computed value.
This is expected — the converter extracts literal values from the SQL text; it cannot execute SQL functions. Replace such values manually if you need the actual computed result in the CSV.
A string value containing a comma was split into multiple columns.
This means the value was not properly single-quoted in the source SQL. Check that every string literal in your INSERT statement is wrapped in single quotes, even ones that do not obviously need it.
Rows from a second table appear mixed into the same CSV as the first table.
Only INSERT statements sharing the same table name are combined into one CSV. If you pasted statements for multiple tables, convert each table's block separately, one conversion per table.
Apostrophes in names look doubled or missing in the CSV.
SQL string escaping uses doubled single quotes (O''Brien). The converter should unescape those to O'Brien. If something looks wrong, inspect the source literal quoting first.
NULL tokens appear as the text NULL instead of empty cells.
Unquoted NULL keywords are often carried through as text depending on how the tuple was parsed. Replace or map them in the spreadsheet if your workflow expects blanks.

Best practices

  • Paste only the INSERT statements you need — remove CREATE TABLE, ALTER, and other DDL statements first for a cleaner parse.
  • Convert one table's INSERT block at a time if your dump covers multiple tables.
  • Double-check that all string literals in the source SQL are quoted, even short ones like status codes, since unquoted strings can be misread as column breaks.
  • Keep a copy of the original SQL dump until you have confirmed the CSV output matches expectations.
  • Prefer dumps with explicit column lists so headers stay stable across schema churn.
  • Spot-check row counts against the number of VALUES tuples you expect before sharing.
  • For production analysis, treat the CSV as a read-only extract — regenerate from SQL if the seed changes.

What SQL to CSV conversion actually does

INSERT statements are a transport format for row data inside SQL scripts. Spreadsheets are a review and analysis format. This conversion extracts the tabular payload from INSERT text without running SQL against a live database.

You get headers from the column list and rows from VALUES tuples. That is ideal for code review of seeds, quick charts, and sharing samples with people who should not get database credentials.

It is not a full SQL engine. Joins, selects, triggers, and functions are out of scope. Stick to literal INSERT batches for predictable results.

When to convert SQL INSERT dumps to CSV

Convert when you need to eyeball seed content, compare environments, or feed a BI-style sheet. Convert when a teammate needs sample rows and exporting from a live DB is blocked.

Keep data in SQL when you must re-apply the same script with transactions, identity overrides, or DB-specific syntax. Round-tripping through CSV and back can change quoting and typing details.

A practical pattern: extract INSERT blocks from a dump, convert to CSV for review, keep the .sql as the apply artifact.

  • Good fit: seed review, dump excerpts, fixture sharing, migration spot-checks.
  • Poor fit: INSERT ... SELECT pipelines, dynamic SQL, statements without column lists.
  • Better as a script: recurring ETL from dumps with schema validation and typed casting.

Supported INSERT shapes and dump dialects

ANSI-style INSERT INTO t (a, b) VALUES (1, 'x'), (2, 'y'); is the happy path. PostgreSQL and MySQL dumps often emit this shape for data sections.

Extended inserts with many tuples in one VALUES clause are fine — each tuple becomes a row. Multiple statements for the same table append rows into one sheet.

Dialect quirks (backtick identifiers in MySQL, quoted identifiers in PostgreSQL) may appear around table or column names. Focus on clean column lists and consistently quoted string literals for best results.

String escaping, commas, and apostrophes

SQL strings use single quotes. An apostrophe inside a string is doubled. The converter strips outer quotes and unescapes doubles so spreadsheet cells read naturally.

Commas inside quoted strings must not create new columns. If a dump was hand-edited and lost quotes, columns will shift — fix the SQL first, not the CSV afterward.

Double-quote identifiers ("My Column") are about names, not values. Keep value literals on single-quote SQL string rules unless your dialect documents otherwise.

Functions, NULLs, and non-literal values

NOW(), CURRENT_TIMESTAMP, UUID(), sequences, and similar tokens are not executed. Cells will show the function text. Replace manually if you need concrete timestamps or IDs in the sheet.

NULL may appear as text depending on tokenization. Decide whether your analysis wants blank cells or an explicit NULL marker, then clean in the spreadsheet or Online CSV Editor.

Binary or hex literals and dollar-quoted PostgreSQL strings can be awkward in a generic parser — simplify to ordinary quoted strings when you need a clean CSV extract.

Multi-table dumps and batching strategy

Full dumps interleave tables. Convert one table’s INSERT section at a time so headers stay coherent and foreign-key order is easier to reason about in separate sheets.

If statements for the same table are scattered, collecting them into one paste still works when the table name matches — rows append into one CSV.

For very large tables, convert chunks of INSERT statements and concatenate CSVs carefully (one header only on the first file).

Excel, Sheets, and post-download typing

CSV has no types. IDs with leading zeros and long numerics may be altered by Excel on open. Format columns as Text or import via a wizard.

Dates that were SQL date literals become text; spreadsheet apps may re-parse them by locale. Prefer ISO-like strings in seeds when you control the dump.

Semicolon-locale Excels may need an explicit comma delimiter on import. Google Sheets usually handles UTF-8 CSV uploads well.

Typical workflows

Seed review: paste the users or products INSERT block, scan for bad emails or prices in Sheets, fix the SQL, re-dump.

Support: share a redacted CSV sample from a staging dump without granting DB access.

Pipeline prototypes: turn SQL fixtures into CSV to feed a converter chain (CSV to JSON, etc.).

Migration audits: convert before/after INSERT batches and diff row counts and key columns.

Browser limits, privacy, and large dumps

Parsing is local. SQL text is not sent to Convert CSV servers for the transform. Site analytics and advertising follow the privacy policy separately.

Multi-megabyte dumps can stress the tab. Extract one table or a row-limited sample first. Use command-line SQL tools for bulk warehouse-scale extracts.

Dumps often contain PII. Even with local conversion, redact before sharing spreadsheets and clear downloads on shared machines.

SQL to CSV versus querying the database

A live SELECT ... COPY or client export gives typed results and current data. Prefer that when you have access and need accuracy.

This converter wins when you only have a .sql file, offline review, or a seed sitting in git. No connection string, no driver setup.

Teams often use both: DB export for production analytics, INSERT-to-CSV for fixture and migration review.

Quality checklist before you share the CSV

Match row count to VALUES tuples. Confirm headers equal the INSERT column list. Spot-check quoted strings with commas and apostrophes.

Search for function call text you did not expect. Open in the recipient’s spreadsheet app and verify ID columns. Keep the .sql until sign-off.

  • Row count matches VALUES tuples.
  • Headers match the INSERT column list.
  • Commas inside strings stayed in one cell.
  • Functions/NULLs handled as your workflow expects.
  • Original SQL retained for re-apply.

pg_dump and mysqldump practical tips

In many dumps, data appears after schema DDL. Jump to the COPY or INSERT section for your table. If the dump uses COPY FROM stdin instead of INSERT, this INSERT-focused converter will not help — export as INSERT or query the DB instead.

mysqldump extended inserts pack many rows per statement; that is fine. Watch character sets — export UTF-8 so names and notes survive into CSV.

If column order in INSERT lists changed between dump versions, compare headers carefully before assuming two CSVs align for a diff.

Security, redaction, and sharing extracts

Seed files and dumps frequently include emails, phone numbers, tokens, or internal IDs. Converting to CSV makes that data easier to redistribute accidentally because spreadsheets travel through chat and email more casually than .sql files.

Before sharing, delete or mask sensitive columns in the Online CSV Editor, or convert a filtered INSERT excerpt that never included those columns. Prefer synthetic fixtures for external contractors whenever possible.

Even though conversion is local to your browser, the downloaded CSV still lives on disk. Clear temporary downloads after a review session on shared laptops, and avoid committing production dumps to public repositories.

If you must share production-like shapes, keep row counts small, replace real PII with placeholders, and document that the file is a redacted extract rather than a full dump.

Comparing environments with two CSV extracts

A common review trick is to convert staging and production seed excerpts for the same table, then compare row counts and key columns in a spreadsheet. Align on the same INSERT column list order first so headers match.

Sort both sheets by primary key before comparing. Differences in optional columns often show up as blanks versus populated cells rather than missing rows.

When timestamps differ because dumps used NOW(), expect function text or divergent literals — those columns are poor diff keys. Prefer stable business keys for environment comparison.

Related tools and next steps

Generate INSERT statements from a spreadsheet with CSV to SQL. Continue into JSON or XML with the other CSV output tools after you have a clean sheet.

Clean columns in the Online CSV Editor if you need to drop function-text cells or normalize NULLs before sharing. Format guides on the site cover CSV delimiters and Excel import quirks when the spreadsheet open step is the real problem. When you are done reviewing, regenerate INSERT SQL from the cleaned sheet only if you intentionally want a round-trip — otherwise keep the original dump as the apply source.

Frequently asked questions

Does this support INSERT statements from any specific database?

It recognizes standard ANSI SQL INSERT INTO ... VALUES syntax, which is common to pg_dump (PostgreSQL), mysqldump (MySQL), and most hand-written seed files.

Can it handle multiple INSERT statements for the same table?

Yes. Multiple statements targeting the same table name are combined into a single CSV with all their rows.

What happens to SQL functions like NOW() or UUID()?

They are extracted as literal text since the converter parses SQL syntax rather than executing it — the CSV cell will contain the function call text itself, not a computed value.

Are column data types (INT, VARCHAR) needed for this to work?

No. Only the column names from the INSERT statement's header and the literal values in each VALUES clause are used — type information is not required.

Is my SQL file uploaded to a server?

No. Parsing happens entirely in your browser. See the Privacy Policy for site analytics and advertising.

How do I go from CSV back to SQL INSERT statements?

Use the CSV to SQL converter, which generates INSERT statements from your spreadsheet's headers and rows.

Does INSERT ... SELECT work?

No. Without a literal VALUES list and a clear column header list in the INSERT, the tool cannot build a reliable CSV table.

What if my INSERT omits the column list?

Add an explicit column list before converting, or export again with columns included. Headers cannot be inferred safely from values alone.

Is there a file size limit?

There is no fixed server quota, but large dumps can exhaust browser memory. Convert one table or smaller batches at a time.

How are apostrophes in strings handled?

SQL escaping doubles single quotes inside literals. The converter unescapes them so O''Brien becomes O'Brien in the CSV cell.

Can I convert COPY FROM stdin PostgreSQL sections?

This page targets INSERT ... VALUES. For COPY blocks, use database tooling or convert those exports another way.

Will boolean and numeric types be preserved?

CSV stores text. Numbers usually look the same; booleans appear as whatever literal was in SQL (true/false/0/1). Cast in the spreadsheet or importer as needed.

Can I paste a mix of INSERT and UPDATE statements?

Only INSERT ... VALUES rows are extracted into the CSV. UPDATE, DELETE, and DDL statements are ignored for table building — remove them first if they clutter the paste or confuse review.

For more background on data formats and conversion workflows, read our format guides or browse the converter blog for step-by-step walkthroughs linked to each tool.