Convert CSV to XLSX or ODS with cell types that keep leading zeros, long IDs and dates intact
Initializing in your browser…
Convert both ways, converting a type only when it reads back the same, and naming every value that cannot
Convert images between PNG, JPG, WebP, AVIF, BMP formats. Features quality control, transparency support, and batch conversion for efficient workflow.
View, sort and edit a CSV, with an undo stack that goes back exactly one step and a parse report that tells a broken quote from a ragged row
An inventory export holds postcodes with leading zeros, prices with a currency symbol, margins as percentages and a 20 digit supplier reference. Opened as a plain CSV, three of those four columns arrive wrong.
inventory.csv
zip,price,margin,supplier_ref 07030,"$1,299.99",18%,12345678901234567890 00501,$29.99,0.5%,98765432109876543210
inventory.xlsx, as LibreOffice shows it
zip price margin supplier_ref 07030 $1,299.99 18.0% 12345678901234567890 00501 $29.99 0.5% 98765432109876543210 zip text a leading zero is lost forever as a number price $#,##0.00 the number 1299.99, so SUM works margin 0.0% 0.5% is the number 0.005, not 0.5 supplier_ref text 20 significant digits, and a spreadsheet keeps 15
Every column is read before a type is chosen, and the two a number would damage are kept as text with the reason shown on the page. The margin column is worth looking at twice: reading 0.5% as a half rather than as five thousandths is a hundredfold error that looks entirely plausible in a spreadsheet, and it is what the previous version of this tool did. Every value above was produced by opening the generated workbook in LibreOffice and reading the cells back.
Convert a CSV file into a real Excel workbook (.xlsx) or OpenDocument spreadsheet (.ods) in your browser. Each column is read first and given the cell type that carries every one of its values without changing them, so a postcode column of 01234 arrives as 01234 rather than as 1234, and a price column arrives as numbers a spreadsheet can add up.
A converter has one job: the spreadsheet has to hold what the CSV held. That is measured rather than claimed here. LibreOffice opens the generated workbook and every cell it shows is compared against the cell the file started with, which is how the conversion was checked at every step.
Column types are decided from the data, not from a pattern race. A column whose digits carry a leading zero is text, because stored as a number the zero is gone and cannot be recovered. A column holding a value with more than 15 significant digits is text, because 15 is the number precision in Excel’s own specifications and limits, so a 20 digit account number cannot be a number in any spreadsheet. The demotion is at column level: a numeric column in which some cells were quietly kept as text is worse than a text column, because SUM skips text without saying so.
Dates are converted from their calendar fields straight to the workbook day number, with no Date object and no timezone anywhere in the path, so the same CSV produces the same workbook in Tokyo and in New York. A percent sign is what makes a value a percentage, so 0.5% is stored as 0.005 and 1% as 0.01. The display format is derived from the column’s own text, so a file written 1299.99 comes back reading 1299.99 rather than 1,299.99, and a column that wrote its negatives as (500) gets Excel’s accounting layout so they still read as (500).
Everything the tool could not carry as the column’s type is listed on the page with the reason, rather than being changed in silence. You can override any column’s format by hand (Automatic, Text, Number, Currency, Percentage, Date, Date and time, Time), and a value that would be destroyed by the format you chose is still kept as text and reported. Sheet names are made legal against Excel’s rules before the file is built, so a CSV called something with a bracket in it converts instead of failing. Large files can be split into sheets of a chosen size, which is what Excel’s 1,048,576 row limit is for. This is a one-way tool: it reads CSV text and writes a spreadsheet, and does not import existing .xlsx files.
Columns whose digits carry a leading zero, and identifiers too long for a number to hold, are kept as text automatically. This is the failure that makes people distrust CSV imports, and it does not happen here.
Numbers arrive as numbers so SUM and sorting work immediately, without the "number stored as text" warning that a renamed CSV produces.
Set rows per sheet and the data is split across named worksheets in one workbook, each carrying the header row.
The ODS output is a real OpenDocument spreadsheet rather than a workbook with the extension changed.
Yes, automatically. A column with any leading zero in it is written as text, and the panel says which value proved it. You do not have to set anything.
It is written as text, and the page says why: a spreadsheet keeps 15 significant digits, so stored as a number the last digits change. As text every digit survives.
Yes. The day number is computed from the year, month and day, so nothing in the conversion depends on where you are. This was checked by converting the same file in New York, Tokyo and Kiritimati and comparing the three workbooks.
Excel keeps a 29 February 1900 that never existed, inherited from Lotus 1-2-3, and LibreOffice does not compensate for it. So the two read a workbook date before 1 March 1900 one day apart, and there is no serial number that both agree on. Text loses nothing; a silent one day shift does.
No. This tool reads CSV input only and writes a spreadsheet. It does not parse existing .xlsx or .ods files.
XLS is the pre-2007 binary format and writing it honestly in a browser is not practical. XLSX opens in every version of Excel from 2007 onward and in Google Sheets and LibreOffice, and ODS covers the OpenDocument side. An option that silently produced a different format than the one it named was worse than not offering it.
Rows and columns are parsed and transformed in memory in your browser. No record ever reaches a server.