SQL to Excel Converter — INSERT Dumps to .xlsx

How SQL to Excel conversion works

SQL to Excel Converter — INSERT Dump to .xlsx | SyntaxFiddle runs SQL INSERT statements through a deterministic, fully client-side pipeline and produces Excel 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 Excel: dump analysis without a database

The classic reason this converter exists: someone hands you a .sql file of INSERT statements and asks a question about the data, and the answer should not require provisioning a database. Paste the dump, get a workbook: column lists become headers, multi-row VALUES tuples become rows, repeated statements merge, '' un-escapes to ', NULL becomes an empty cell, and numerics keep their types into real numeric cells.

The boundary is the same honest one the SQL-to-CSV converter states: values must be literals. pg_dump --inserts and mysqldump's default output parse natively; INSERT ... SELECT and placeholder-parameterized statements contain no rows to extract and are rejected with a specific message. Nothing executes, nothing connects, nothing uploads — the dump is read as text in your browser and the workbook is written by it.

A real .xlsx workbook, not CSV wearing an extension

The download is a genuine Office Open XML workbook: cells carry types, not text. Numbers land as numeric cells that Excel aggregates with SUM and AVERAGE, booleans land as TRUE/FALSE cells, and nulls become empty cells rather than the string 'null' — so filters, pivots, and charts behave the instant the file opens. Column widths are sized to content (capped at 40 characters) so the first impression is a readable sheet, not a wall of ####.

The preview pane shows the equivalent CSV while the workbook generates, so you can sanity-check the data before downloading. Everything — parsing, row extraction, workbook generation — runs in the same client-side pipeline as every other target, guarded by the worker and the 15MB cap.

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. Open the downloaded .xlsx in Excel, Numbers, or LibreOffice — typed cells and sized columns are already in place, so pivot tables work on first open.

How do I convert SQL INSERTs to Excel?

Paste INSERT INTO ... VALUES statements — multi-row tuples and multiple statements are merged automatically — pick Excel as the target, and press Run Conversion. The Download button produces a real .xlsx workbook with the column list from your statement as the header row.

Does it connect to a database?

No. There is no database connection, driver, or execution of any kind — the parser reads the INSERT text as text, extracting column names and literal value tuples exactly as written. That also makes it safe for production dumps: nothing executes and nothing leaves your machine.

How are NULLs and booleans handled?

NULL becomes an empty cell, TRUE/FALSE become native boolean cells, and numeric literals keep their values as typed numeric cells. String literals honor SQL's doubled-quote escaping, so O''Brien converts to O'Brien with the apostrophe intact.

Can I convert a mysqldump or pg_dump file?

Yes, if it was exported with literal INSERT statements (pg_dump --inserts, or mysqldump's default format). The CREATE TABLE block is skipped and every INSERT tuple is merged into one table. Statements using placeholders or INSERT ... SELECT contain no literal rows and are rejected with a specific message.

Is my SQL dump uploaded anywhere?

Never. Parsing and workbook generation run in your browser inside a Web Worker — no upload endpoint exists, nothing is logged, and the tool works offline once loaded. Production data stays on your machine.

What about the CREATE TABLE statement in my dump?

It is skipped automatically — the parser is after rows, not DDL. Column types are inferred from the actual values in the tuples (numbers as numeric cells, booleans as TRUE/FALSE, everything else text), which is more honest than trusting a schema that may not match the data. The INSERT statements' column list, quoted or bare, becomes the header row.

How fast is a large dump converted?

Parsing is single-pass and linear in the dump's size, with anything over 1MB handled inside a background Web Worker so the tab stays interactive. The 15MB cap covers dumps of roughly a million short rows — and because nothing uploads, the network is never the bottleneck; your CPU does the whole job locally.