Excel to JSON, CSV and SQL

What this tool does

It opens an .xlsx file inside your browser and converts it to three formats:

• JSON — an array of objects using the first row as keys.
• CSV — configurable delimiter, quoting per RFC 4180.
• SQL — batched INSERT statements, with a CREATE TABLE inferred from your data, for MySQL, PostgreSQL or SQLite.

The file is not uploaded to any server. It is read, converted and downloaded without leaving your machine, which matters when the sheet holds payroll, supplier pricing or customer data.

How to use it

1. Drop the .xlsx onto the upload area, or click to pick it.
2. If it has several sheets, choose one.
3. Tick whether the first row contains headers.
4. Choose the output format, adjust the options and copy or download.

Dates: why almost every converter gets them wrong

If you have ever converted an Excel file and found a column of 45000, 45001, 45002 where you expected dates, this is why.

In an .xlsx file, dates do not exist as a data type. A date is stored as a number: days elapsed since a reference point. The 45000 above is 15 March 2023.

The only thing separating that number from any other quantity is the format applied to the cell, and that format lives in a separate file inside the .xlsx (xl/styles.xml). A converter that does not read it sees a number and copies a number. It is not broken: it is not looking in the right place.

This tool reads the style sheet, recognises date formats — both the ones Excel ships with and the custom ones you defined — and returns a real ISO date.

And the 1900 bug, dragged along for 40 years

Here is the detail almost no home-made implementation gets right.

Excel believes 1900 was a leap year. It was not: years divisible by 100 are not leap years unless they are also divisible by 400, and 1900 is not. The error comes from Lotus 1-2-3, which had it wrong in the eighties, and Microsoft copied it deliberately for compatibility: Microsoft documents it themselves. It has never been fixed because fixing it would shift every date in every spreadsheet in the world.

The consequence is concrete: serial number 60 is a 29 February 1900 that never existed, and that splits the conversion into two ranges:

With a single reference you are right in one range and a whole day off in the other. And since real data almost always sits above serial 61, the bug never shows… until somebody enters an old date of birth and the conversion shifts it by a day.

Types are inferred from the data, not the header

Before generating anything, the tool walks each full column and assigns it a type, with a conservative rule: the type only applies if every non-empty value satisfies it. As soon as one value does not fit, the column falls back to text.

It also flags whether the column allows empties, and that is what decides the NOT NULL in the CREATE TABLE.

The type table is shown on screen before converting, so you can see at a glance whether a column is being read as text because it holds a dirty value: an “N/A” in a numeric column, a cell with a stray space, a hand-typed total at the bottom.

About the SQL it generates

It emits a CREATE TABLE with the inferred types and then the INSERTs grouped into batches (100 rows per statement by default, configurable). The three engines are treated as what they are:

Escaping. Values are always escaped by doubling the single quote (O'Brien → 'O''Brien'), which is what the SQL standard says and what all three engines understand identically. Backslashes are deliberately not used: in MySQL they work, but their behaviour depends on the NO_BACKSLASH_ESCAPES mode, and escaping that depends on server configuration is not escaping.

Even so, review the CREATE TABLE before running it. The types and lengths are a reasonable proposal derived from the sample you gave it, not a schema design: it does not know which field is the primary key, which one needs an index, or whether that text column is going to grow.

Headers get sanitised too

An Excel header can be Fecha de alta, Precio ($) or 2026 total, and none of the three works as a column name. Next to the original name you will see the generated identifier:

• Fecha de alta → fecha_de_alta
• Año → ano (no accents, no ñ)
• Precio ($) → precio
• 2026 total → col_2026_total (no engine accepts an identifier starting with a digit)
• An empty header → col_3, from its position

And if two headers produce the same identifier — id, ID and Id are the same thing once sanitised — a numeric suffix is added so the CREATE TABLE does not fail.

Which formats it accepts

Only .xlsx, the format from Office 2007 onwards. Files exported by Google Sheets, LibreOffice Calc and Numbers also work, since they follow the same standard.

What it does not accept:

• .xls (Office 2003 and earlier). It is an entirely different binary, not a ZIP of XML. Open it in Excel or LibreOffice and save it as .xlsx.
• .csv. It is already plain text; the JSON and CSV converter covers that.
• .ods from LibreOffice. Save it as .xlsx.

No external dependencies, and why that matters here

An .xlsx is a ZIP full of XML. Reading it takes two things the browser already ships: DecompressionStream to decompress and an XML parser.

It is worth saying why the usual library for this is not used. The xlsx package on npm is frozen at version 0.18.5 from 2022 and carries two known vulnerabilities — prototype pollution (CVE-2023-30533) and a regular-expression denial of service (CVE-2024-22363). Its authors moved distribution to their own CDN and never published the fixes to npm, so installing xlsx from there today means installing the vulnerabilities. Writing the reader, by contrast, is around three hundred lines and adds no attack surface.