Convert SQL to Excel

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 becomes 1234, which quietly turns a valid postcode into an invalid one. And anything shaped remotely like a date becomes one, so a part number written 3-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.

A SQL file and a workbook, in brief

SQL

Full name	Structured Query Language
Extension	.sql
Format type	Plain text statements, not a data format
MIME type	application/sql

XLSX

Full name	Office Open XML Workbook
Extension	.xlsx
Format type	Spreadsheet — a ZIP archive of XML parts
MIME type	application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

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. If one of those codes is a GTIN-12, the intact text can go straight into the UPC generator; the spreadsheet should store the identifier, while the generator handles the UPC-A symbol. A mixed letter-and-number asset ID belongs in the barcode generator as Code 128 instead; changing its symbol must never change the value the workbook preserved.

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.

What usually happens next is an edit, and then the rows need to go back. Excel to SQL reads the workbook in the other direction and writes the INSERT statements, with one asymmetry worth expecting: an .xlsx records what a cell looks like rather than what the column was declared as, so the types have to be inferred afresh and are shown to you before anything is generated.

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 like O'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 recognized 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.