What a cell actually stores
A spreadsheet cell holds two separate things: a value and a number format. The value 0.15 can display as 15%, as 0.15, as £0.15 or as 15.00%, and none of that display changes the value by a hair. This is the single most useful fact about spreadsheets, and it is why Excel to CSV asks you to choose between "as shown" and "raw values" rather than guessing. "As shown" writes exactly the text on screen — 15/03/2024, 1,234.50, 12% — which is what Excel's own Save As does and what a human reading the CSV expects. "Raw values" writes plain numbers and ISO dates, which is what a database or a script expects. Pick the wrong one and the import fails in a way that looks like the data is corrupt.
Dates are numbers pretending to be dates. A date cell holds a serial day count, and the epoch it counts from depends on the file: workbooks written by Windows Excel count from 1900, workbooks from the old Mac Excel count from 1904, and the two are 1,462 days apart. The 1900 system is stranger still — it believes 29 February 1900 existed, a bug inherited from Lotus 1-2-3 and kept ever since for compatibility. The tools here read each workbook's own epoch flag and reproduce the fake leap day exactly where it belongs, which is why a date converted here matches what Excel shows rather than sliding by four years and a day.
A formula and its result are stored side by side. A workbook keeps the formula text and the last value it calculated. Workbook-to-workbook conversions — ODS to XLSX, XLS to XLSX, XLSX to ODS — carry the formulas themselves, translated between the two function vocabularies, so the sheet still recalculates when you edit it; the handful of functions that exist on only one side show as #NAME? until you replace them. Everything that leaves the spreadsheet world — CSV, JSON, XML — carries the calculated result only, because none of those formats has any concept of a formula.
CSV cannot represent most of a workbook, and pretending otherwise is where data gets lost. It has no sheets, so each sheet becomes its own file (and a ZIP if you want all of them). It has no cell types, so every field is text until something guesses. It has no formats, no formulas, no charts, no images, no colours, no column widths. Merged cells have to be resolved one way or the other — the value in the first cell, or repeated across the merge. And it does not record its own delimiter, its decimal separator or its encoding, which is why a European semicolon file with commas for decimals lands in one column in a US Excel, and why accented text turns to mojibake unless the file starts with a byte-order mark.
Text that looks like a number is where real damage happens. Excel guesses cell by cell when you open a CSV: ZIP code 01234 loses its zero, a 16-digit order ID becomes 1.23457E+15 and cannot be recovered, and the gene name SEPT2 becomes a date — a problem serious enough that the genetics community renamed its genes. CSV to Excel decides once per column instead, from every value in it, and only converts when the whole column agrees; anything with leading zeros, and any integer too long for a JavaScript number to hold exactly, stays text. JSON to CSV applies the same care in reverse, copying 64-bit IDs digit for digit where most converters round them.
JSON and XML each drop something of their own. JSON has no date type at all, so dates travel as text and the receiving code has to know what it is looking at. Data XML carries values only, with no formatting, charts or images — which is exactly what an import feed wants, and not what you want if the point was to keep the workbook intact.
Where a browser is genuinely the wrong tool
Seven of these tools run entirely on your device: Excel to CSV, CSV to Excel, CSV to JSON, JSON to CSV, XML to Excel, Excel to XML and PDF to Excel. Nothing is sent anywhere, which matters when the file is a payroll or a customer list. Four are different — Excel to PDF, ODS to XLSX, XLS to XLSX and XLSX to ODS hand the file to LibreOffice Calc on our server, because laying out a printed page, or carrying fonts, colours, conditional formatting and charts across formats, is not something a browser library does. Those files go over an encrypted connection, are converted, and are deleted the moment your download is ready. Each has an in-browser fallback if the engine is unreachable, which keeps values, formulas, number formats, merged cells and column widths but not fonts, colours or charts, and tells you it has done so.
Size. The browser-side tools hold the whole table in memory, so the ceiling is your tab's memory budget — comfortable into the tens of megabytes, awkward past a hundred, and hopeless for a multi-gigabyte extract. The workbook converters cap at 50 MB per file and Excel to PDF at 40 MB, and both say so before converting rather than after. An Excel sheet itself stops at 1,048,576 rows, which is a limit of the format, not of us; CSV to Excel continues onto extra sheets with the header repeated rather than truncating your data silently.
Real data work. A converter is not a database. Joining two tables, deduplicating, aggregating, filtering ten million rows or profiling a messy export are jobs for tools built for it, and the free ones are very good: csvkit for quick command-line CSV surgery, Miller for the same on JSON and CSV together, qsv for speed on enormous files, DuckDB to run actual SQL straight over a CSV or Parquet file, pandas if you are already in Python.
Macros, and anything that runs. VBA cannot be carried into .xlsx, which simply has no place to put it, and it is not carried into .ods either because LibreOffice runs only part of VBA and the differences would appear as wrong numbers rather than as errors. If a workbook depends on its macros, keep the original alongside the converted copy. Password-protected files must have the password removed first, in the program that set it.
Automation. These tools run when a person clicks. Converting a nightly feed is a command-line job: LibreOffice in headless mode does every format on this page, and it is the same engine our server converters use.
Choosing between the tools that sound alike
Excel to CSV vs Excel to XML. Both read a workbook and write a flat data file, and the destination decides. CSV goes to spreadsheets, databases and anything that says "upload a CSV". XML goes to imports and integrations that specify element names — you set the root and row names, headers become element names, and values come out as plain numbers and ISO dates. Excel to XML can also write XML Spreadsheet 2003, which is a completely different thing: a format Excel reopens as a workbook, for when a system asks for "Excel XML" rather than your own data XML.
CSV to Excel vs CSV to JSON. Same parser, same per-column type detection, different output. CSV to Excel produces an .xlsx with real dates and numbers you can sum and sort, and a frozen filterable header row — for people. CSV to JSON produces an array of objects, an array of arrays, a keyed object or JSON Lines — for code. If the answer is "both", convert to Excel for the humans and JSON for the pipeline; they will agree, because the column types were decided the same way.
XML to Excel vs Excel to XML. Not simply opposite directions. XML to Excel has to find the table first: it looks for elements that repeat under the same parent — every <book> in a catalogue, every <item> in an RSS feed — scores each group and offers the rest one click away, then flattens attributes and nested elements into path-named columns. Excel to XML has no finding to do, because your rows are already the records.
XLS to XLSX vs CSV to Excel. Both end in a modern workbook. XLS to XLSX upgrades a real Excel 97–2003 binary file and keeps everything in it — sheets, formulas, formatting, charts. CSV to Excel builds a workbook from plain text that never had any of that. The overlap is the annoying middle case: plenty of web apps export an HTML table or an XML file and name it .xls. XLS to XLSX recognises those for what they really are and saves a genuine workbook.
PDF to Excel vs Excel to PDF. Opposite directions, and only one of them is reliable. Excel to PDF is a layout job: the workbook already knows its print area, its page breaks and its formatting, and the engine draws them. PDF to Excel is the hard direction, because a PDF records where each character was painted and nothing about which cell it belonged to — the columns are inferred from position. It works well on clean, ruled tables, needs tidying where cells are merged or wrap onto several lines, recreates values rather than formatting or formulas, and gives each PDF page its own sheet. If the original workbook still exists, ask for it.
ODS to XLSX vs Excel to CSV for an .ods file. Excel to CSV happily opens .ods and gives you the values. ODS to XLSX keeps the workbook as a workbook, with its formulas, formatting and charts. Use the converter when someone needs to work in the file, and the CSV route when a system needs the numbers out of it.