CSV to Excel converter
Turn a CSV or TSV into a formatted .xlsx without Excel eating your leading zeros, mangling anything date-shaped or rewriting long numbers.
Drop your file here
It is processed on your device — nothing is uploaded.
The problem is not the file format
Excel opens CSV files perfectly well. What it does badly is decide what the values mean, and because a CSV carries no type information it has to guess. It guesses wrongly in five specific ways, all of them silent, and every one of them is a real support ticket somewhere this week.
Leading zeros disappear. A column of postcodes, PIN codes, phone numbers, account numbers or internal part numbers arrives as numbers, and 00123 becomes 123. There is no warning and no undo, because as far as the spreadsheet is concerned nothing was lost.
Anything date-shaped becomes a date. A value of 3-4 turns into a day in March. This is not a hypothetical: human geneticists ended up renaming genes because SEPT1 and MARCH1 kept arriving as dates in shared spreadsheets, and the rename was judged easier than getting everyone to import their files correctly.
Long numbers go to scientific notation. An 18-digit identifier becomes 1.23457E+17, and past fifteen significant figures the original digits are not recoverable — the number that came back is genuinely a different number.
A leading = + - or @ is treated as a formula. Cosmetically that gives you an error in a cell. Less cosmetically, it is how a value in an exported spreadsheet ends up executing when somebody opens it.
UTF-8 without a byte-order mark is read in the system codepage. Every accented, Cyrillic, Greek, Arabic, Devanagari or CJK character in the file arrives as mojibake.
Declaring the type instead of guessing it
An .xlsx file states the type of every single cell. So the fix for all five is the same: read the CSV, decide once what each value is, and write it down explicitly. Excel then has nothing to guess about, and the fifth problem disappears entirely because .xlsx is XML and therefore always UTF-8.
The default policy stores a value as a number only when doing so cannot change what it says, and that is checked two ways because either one alone lets damage through. First a round trip: a value becomes a number only if converting it and converting it back gives identical text, which rules out 00123, +44, 1,200, (50) and 12345678901234567890. Then Excel's own precision limit, which is the trap — Excel keeps fifteen significant digits and deliberately zeroes the rest, so 1234567890123456 comes back as 1234567890123460 even though it is comfortably inside what a computer can hold exactly. The destination's limit governs, not the language's. 42, -3.5 and 1234567890.12345 are numbers; anything with more than fifteen significant digits is not.
Dates, and why most of them stay as text
Real dates are worth having: they sort correctly and they can be subtracted. The optional date mode converts them, but only in ISO 8601 form — 2026-03-04.
Everything else is left alone on purpose. 03/04/2026 is the fourth of March or the third of April depending on which country produced the file, nothing in the file says which, and a wrong guess moves the date by months while looking completely reasonable. A converter cannot resolve that and should not pretend to.
What you get
A single sheet named after your file, with the header row styled, frozen so it stays put while you scroll, and given filter arrows. Column widths are set from the content. It is the spreadsheet you would have made by hand after importing.
The separator is worked out properly
Semicolon-separated files are normal across most of continental Europe, because a comma is the decimal point there — so a French or German export often is not comma-separated at all. Tabs and pipes both turn up in database dumps.
Detection does not simply count commas in the first line, which is the usual approach and which gets it wrong on any file containing an address: "Flat 4, Mill Lane" gives a semicolon-separated file more commas than semicolons. Instead each candidate is used to parse the first twenty-five rows, and the one that splits every row into the same number of fields wins. Consistency identifies a delimiter; frequency does not.
Encoding, decided rather than guessed
A byte-order mark settles it immediately. Failing that, whether the bytes are valid UTF-8 is a decidable question rather than a matter of opinion — UTF-8 is a tightly constrained encoding, and text that is not UTF-8 almost never accidentally passes as UTF-8. So a strict decode that succeeds is the answer, and only one that fails falls back to Windows-1252. The result tells you which it used and why.
It runs in this page
A CSV is what an export button produces, which means the ones people convert are customer lists, payroll runs, order histories and membership databases. Uploading a whole customer list to a free website to change its file format is a poor trade for a job that is some XML in a zip — so nothing is uploaded, and there is no size cap beyond what your machine can hold.
Common questions
Why did Excel remove my leading zeros?
Because a CSV does not say what its values are, so Excel decided the column was numeric and 00123 and 123 are the same number. An .xlsx states the type of every cell, so converting first removes the guess.
Will it keep long ID numbers exactly?
Yes. A value is only stored as a number if converting it and back gives identical text, so anything past fifteen significant figures is kept as text rather than silently rounded.
What about dates?
ISO dates (2026-03-04) can be converted to real dates. Ambiguous formats like 03/04/2026 are deliberately kept as text, because nothing in the file says whether the day or the month comes first.
My file uses semicolons. Does that work?
Yes, and it is detected. Separator detection picks whichever candidate splits every row into the same number of fields, so an address containing commas does not mislead it.
Do you upload my file?
No. It is read and the spreadsheet is written in your browser. That is also why there is no file size limit.
Why is my text full of strange characters?
The CSV was probably saved as UTF-8 without a byte-order mark. Encoding is detected here, and the result says which one was used — if it guessed wrong you can set it by hand.
Can it handle a really large export?
Up to a worksheet\u2019s own limit of 1,048,576 rows and 16,384 columns, which is Excel\u2019s hard ceiling rather than ours. Past that you are told, rather than getting a file that will not open.