CSV carries no types, so something always has to guess

A CSV is text with separators. Every cell is a string, and nothing in the file records whether a value is a number, a date, or a code that merely looks like one. So whatever opens it has to decide — and it decides silently.

What the guessing costs

• Leading zeros vanish. A postcode 007890 or an ID 00234 is read as 7890 and 234. Save the file and the zeros are gone permanently.
• Long digit strings become scientific notation. Beyond about fifteen significant digits an account reference can be displayed, and then saved, as something like 1.23457E+14. The exact digits are unrecoverable, and the file still looks valid — you find out when a lookup fails.
• Dates flip. A value meaning the third of April can be read as the fourth of March depending on regional settings. This is the worst of the three because the result is still a valid date, so nothing looks broken and no error appears anywhere.

What these share: they are not display glitches. Once a misread value is written back to disk the original is gone, and the file continues to look correct to everyone who opens it afterwards.

What converting to XLSX actually does — stated honestly

This is where most pages on the subject overpromise, so be clear about it.

XLSX stores a type alongside each value, so once the file is XLSX the type is recorded and stops being re-guessed every time the file is opened. That is the real benefit, and it is genuine.

But the first guess still has to happen. The CSV contains no type information, so the converter infers types from the text exactly as a spreadsheet would. It cannot know that 007890 was meant to stay a code, because nothing in the file says so. Converting moves the decision from your spreadsheet's import to this parser — a different guess, not the absence of one.

So the honest claim is narrower and still useful: converting early freezes one interpretation instead of letting every subsequent reader make a fresh one, and it removes the delimiter and encoding ambiguity that makes CSV fragile between systems.

How to actually protect a code column

Since no converter can infer intent, the protection has to be explicit:

• Keep the original export untouched. It is the only copy that definitely still has the right digits.
• Use the import dialog rather than double-clicking the file, and mark code columns as text before the data lands. This is the step that actually works.
• Format the column as text in the resulting workbook, so later edits do not reintroduce the problem.
• Export with quoting from the source system where that is an option, which at least signals intent to readers that honour it.

The other reasons to convert

Beyond types: you are sending a file in the format the recipient expects, column widths and formatting survive, and a single sheet in a defined encoding removes the guesswork about whether a file is comma or semicolon separated and which character set it used.

The tool uses SheetJS, detects the delimiter — comma, semicolon, tab or pipe — and runs entirely in your browser, so the file is never uploaded. For the reverse, see the XLSX to CSV converter.