Convert SQL to Excel
Writes a real .xlsx workbook where every cell is text, so nineteen-digit IDs and leading zeros arrive intact.
Runs in your browser0 bytes uploadedWaiting
- Tables
- —
- Rows
- —
- Columns
- —
№ 4614waiting
Paste SQL or drop a .sql file. The tables in it are listed first, with their row counts — nothing is uploaded to read them.
Why SQL to Excel should mean a workbook, not a CSV
Because of three things Excel does to your data on the way in, and it is worth being specific about them. When Excel imports text it decides for itself what each value means, and three of those decisions destroy information permanently.
A long identifier becomes scientific notation. An order number of nineteen digits is displayed as 1.23457E+18, and widening the column does not bring the digits back — they were discarded on import, because Excel stores numbers with fifteen significant digits. A leading zero is dropped: 01234 becomes1234, which quietly turns a valid postcode into an invalid one. And anything shaped remotely like a date becomes one, so a part number written3-12 arrives as the twelfth of March.
None of that is an encoding problem, which is why the usual byte order mark advice does not help. It happens after the file has been read correctly.
What a workbook does differently
In an .xlsx, each cell carries its own type inside the file, so nothing has to be guessed at open time. Every cell written here is text. The sheet shows what the database actually holds rather than Excel's interpretation of it, and the columns that needed protecting — IDs, codes, postcodes, phone numbers — are exactly the ones that survive.
It is a real workbook, not a renamed CSV. The file is a zip archive containing the workbook part, the worksheet, the content type declarations and the relationships between them, all assembled here. Excel, LibreOffice, Numbers and Google Sheets open it natively, without the warning Excel shows when an extension does not match the contents. The sheet takes the name of the table it came from.
The dump gets read properly first
Before any of that, the file has to be understood, and a database export is not tidy text. Identifiers may be wrapped in backticks, double quotes or square brackets depending on which engine wrote it. Values contain semicolons, brackets and commas that look like structure and are not. MySQL escapes an apostrophe with a backslash; PostgreSQL does not, and reading one as the other turns a name likeO'Brien into an unterminated string that swallows the rest of the file.
So the dump goes through a tokenizer that resolves all of that first, and the dialect it settled on is shown with the evidence for it — you can override the guess if you know better. Only then are the rows read out of the INSERT statements, and index definitions inside a CREATE TABLE are recognised as indexes rather than turned into two extra columns named after them.
One table, one workbook
A limit by design. A backup contains dozens of tables and virtually nobody wants all of them in one file — the useful move is to find the one you need, drop the columns you do not, and get a sheet you can actually work in. Every table is listed with its row count when the file loads, so choosing takes a moment. Run it again for the next one.
There is deliberately no copy button on this page either. A workbook is a binary archive, not text, so it cannot go on the clipboard. The sibling exports to CSV and JSON have one, because for those it is a promise that can be kept.
Nothing is uploaded, and here that is the whole story
The SQL is tokenized and the workbook is zipped in this tab, using compression the browser already provides. There is no server involved at any stage, and no size limit either — a large export is read off the main thread so the page stays usable while it happens.
The reason to care is what you are holding. A database dump is every row of every table: the customer list, the addresses, the order history, whatever a previous developer decided to store in a settings table. Uploading one to a converter in order to get a spreadsheet back is a trade almost nobody would make if the exchange were stated out loud.
Questions
Why a workbook rather than a CSV?
Because a CSV has no types and Excel guesses on import, always in the same three damaging ways. A nineteen-digit order number becomes 1.23457E+18 and the original digits are gone. A postcode written 01234 loses its zero. An ID that happens to look like 3-12 becomes the twelfth of March. In an .xlsx every cell carries its own type, and here every cell is written as text — so the sheet shows what the database holds rather than what Excel assumed it meant.
Is this a real .xlsx or a renamed CSV?
A real one, built here: a zip archive containing the workbook XML, the worksheet, the content types and the relationship parts. Excel, LibreOffice, Numbers and Google Sheets all open it as a native workbook. The renamed-CSV trick is common in tools like this and it produces the security warning Excel shows when a file's extension does not match its contents.
Can I export more than one table at once?
No — one table becomes one workbook, and the sheet takes the table's name. It is a deliberate limit rather than an oversight. A dump has dozens of tables and almost nobody wants all of them; picking one and choosing its columns is the whole point of the flow. Run it again for the second table.
Why is there no copy button?
Because a workbook cannot go on the clipboard. It is a binary archive, not text, so a copy button here would either be broken or would quietly give you something other than what the download contains. The sibling tools that produce CSV and JSON do have one, because for those it is honest.
Does the dump leave my machine?
No. The SQL is tokenized and the workbook is zipped in this tab, using compression the browser already has. That matters here more than almost anywhere else on this site: a database dump contains every row of every table, so uploading one to a converter hands over your entire customer list to get a spreadsheet back.