CSV looks like the simplest file format there is, XML looks like the strictest, and Excel hides what a cell really holds behind what it shows. All three lose data quietly in conversion, for different reasons. These tools convert between Excel, CSV, JSON and XML and break large files into smaller ones — and each of them reports what it found and what it changed, rather than handing back a result and letting you assume it was clean.
Which one to use
| You want to… | Tool |
|---|---|
| Open a CSV in Excel without losing leading zeros or long ID digits | CSV to Excel |
| Combine several CSV files into one workbook, a sheet each | CSV to Excel |
| Export every sheet of a workbook, with full-precision numbers and ISO dates | Excel to CSV |
| Turn a sheet into JSON with real dates and the right header row | Excel to JSON |
| Turn a CSV export into JSON for an API or a script | CSV to JSON |
| Check a CSV for ragged rows and duplicate headers before using it | CSV to JSON |
| Turn an API response or a log dump into a spreadsheet | JSON to CSV |
| Flatten nested JSON into columns you can sort and filter | JSON to CSV |
| Get a file under an importer's row limit | Split CSV — Rows per file |
| Give each region, month or client its own file | Split CSV — A column's value |
| Turn an XML feed or export into JSON without the shape changing between files | XML to JSON |
| Produce XML from JSON without silently renaming two keys into one tag | JSON to XML |
| Get a spreadsheet out of a record-shaped XML document | XML to CSV |
Records are not lines
A field wrapped in quotes may contain a line break, and constantly does — a postal address, a comment box, a description pasted out of a document. That record then occupies several lines in the file while still being one record.
Nearly every quick implementation splits the text on newlines first and looks at quotes afterwards, which means it eventually cuts a record in half. In a converter you get a row that begins mid-sentence with its values under the wrong keys; in a splitter you get two files, one ending on an open quote and one starting in the middle of somebody's address. Nothing raises an error in either case. These tools parse character by character, so a boundary can only fall between records, and they show the file's text-line count beside its record count — when the two differ, you are looking at a file the usual approach would have damaged.
The report is the product
Converting tidy data is not hard and every tool manages it. What separates them is what happens to untidy data, and the standard answer is: something, silently. So each of these pages prints what it found.
| In the file | Usually | Here |
|---|---|---|
| A byte order mark from Excel | Becomes part of the first key, which nothing can then match | Removed, and reported |
| Two columns with the same name | The second overwrites the first in JSON | Renamed, with each rename listed |
| A row with the wrong number of fields | Truncated or shifted into the wrong columns | Counted; surplus fields can be kept |
| A postcode like 00721 | Converted to the number 721 | Kept as text, and counted |
| An Excel cell holding 3.14159, shown as 3.14 | Exported as 3.14 | Exported as 3.14159, with the cell named |
| An Excel date | Exported as 45366 | Exported as 2024-03-15 |
| A key that first appears in record 400 | Dropped, because the header came from record 1 | Given a column, with the count reported |
| An XML element that occurs once in this file and twice in the next | Object one day, array the next; the code reading it breaks | An array both times, and the unstable names listed |
| The JSON keys "user name" and "user_name" | Both become the same XML tag, and nothing says so | Renamed and reported as a collision |
Delimiters, encodings and Excel
The delimiter is detected by counting commas, semicolons, tabs and pipes outside quoted sections, so a semicolon-separated export from a European copy of Excel is read correctly without being told — and the page always says which one it used. Going the other way, the byte order mark is offered as an option rather than forced: Excel on Windows needs it to read UTF-8 without turning accented characters into mojibake, and almost everything else is better off without it.
Two formats, two different ways of losing data
CSV loses data by being loose: no types, no encoding declaration, and a quoted line break that a careless parser cuts in half. XML loses it by being strict in a way that does not survive conversion — it has no way to mark a list, so whether you get an array or an object depends on how many times an element happened to occur in the file you are holding. The CSV pages count what they changed; the XML pages pin down the shape and name the parts that could not come across.
Excel: what a cell shows is not what it holds
An .xlsx file is a zipped bundle of XML parts, and every cell in it has two
values: the one stored and the one displayed through its format. Excel's own Save As
→ CSV writes the displayed one. That is how 3.14159 leaves as 3.14 and a 13-digit
ID leaves as 1.23457E+12. It also exports only the sheet you are looking at. The
Excel to CSV and Excel to JSON
pages write the stored value, turn date serial numbers into ISO dates, and name every
cell where the two differed. They also name formulas that were never calculated, which
the underlying library would otherwise report as 0.
Going the other way has the opposite problem. Opening a CSV in Excel lets Excel guess each value's type, and the guesses are destructive: leading zeros go, digits past the fifteenth become zeros, and gene names become dates. CSV to Excel decides column by column instead and shows you the decision.
Nothing is uploaded
Exports, customer lists and API dumps are read and written inside your browser tab, so there is no upload and no size cap to argue with — only your own machine's memory. That is common enough now not to be the reason to use these tools. The reason is that every number on these pages is one you can check.