data · 6 min read

Why the leading zeros vanish from your CSV

The zeros are still in the file. Something between the disk and your screen decided those digits were a quantity, and quantities do not have leading zeros.

You export a list of postcodes, open it to check, and 07430 has become 7430. Every value in the column is one character short. The export looked fine when you made it.

Why do leading zeros disappear in CSV

They were read as numbers, and numbers have no leading zeros

CSV stores no types — every field is text, and the program opening it guesses. A run of digits looks like a quantity, so 07430 is loaded as the number 7430 and the zero has nowhere to live. The file on disk is unchanged. Open it in a text editor and the zeros are all still there.

in the fileafter the reader guesses07430US postcode7430read as a quantity00961dialling code961read as a quantity0042part number42read as a quantity1E9a reference, not a power1000000000read as a quantitySKU-0042has a letterSKU-0042stays text — cannot be a number00.50a version0.5read as a quantity
The right column is each value put through the page's own number parsing as it renders — the same question a spreadsheet asks, which is whether the field looks like a quantity. Five of six change. Nothing in the file changed with them: the digits are still on disk, and what you are looking at is a guess about what they meant.

Where the guess happens

Nothing in a CSV says what a column contains. There is no header row that declares this one is text, no schema, no types at all — which is the point of the format and the source of most of its trouble. Every reader that wants to put values in columns has to decide what they are, and the only evidence is what they look like.

A field of digits looks like a number. That guess is right almost always: quantities, prices, counts and ages all arrive as digits and all want to be numbers. It is wrong for the class of values that are digits without being quantities — postcodes, part numbers, dialling codes, account references, anything with a fixed width — and for those the guess destroys the leading zeros as a side effect of being helpful.

The moment the damage becomes real

Opening the file does not change it. The zeros are on disk throughout; you are looking at an interpretation. Close the spreadsheet without saving and nothing has happened at all.

Saving writes the interpretation back. At that point the text 07430 is replaced by the number 7430 in the actual file, and the original is gone. So the first move on noticing the problem is not to fix the display — it is to stop, close without saving, and go back in through an import that does not guess.

The import that does not guess

In Excel the double-click path always guesses. The route that does not is Data → From Text/CSV, which shows a preview and lets you set a column's type to Text before anything loads. Set it there and the zeros survive, because you answered the question instead of leaving it open.

Changing the cell format afterwards does nothing. Formatting decides how a stored value is displayed, and by then the stored value is 7430 — there is no zero to display. This is the single most common wasted hour in this whole problem.

The tricks, and what each one costs

A leading apostrophe tells Excel to treat the cell as text. It also gets written into the cell, so the next export carries it and every other program reads it as part of the value. It fixes a spreadsheet and breaks a file.

Wrapping as ="07430" is better inside Excel — it evaluates to text — and worse everywhere else, since anything that is not Excel reads the equals sign and the quotes as literal characters. Reasonable when Excel is certainly the only reader, and a trap the moment the file is passed on.

Quoting the field in the CSV itself — "07430" — feels like it should work and does not. Quotes tell a reader where a field ends, not what type it is; they are punctuation rather than data, and a spreadsheet strips them and then guesses exactly as before.

The same guess, other victims

Once you see the mechanism, the other symptoms are the same one. A field like 3-4 becomes a date, because it looks like one. A long account number becomes 1.23457E+14, because a number that large gets scientific notation. A value of NA becomes something a spreadsheet thinks is missing.

Human genetics has the best-documented casualty: gene symbols like SEPT2 turned into 2-Sep in so many published datasets that the naming committee eventually renamed the genes. That is how hard this guess is to switch off.

Recovering what is already gone

Padding back works only where the width is a rule. A postcode column that is always five digits can be restored with confidence. A part number of unknown length cannot — 42 could have been 042 or 0042, and nothing in the file distinguishes them.

If you still have the original export, go back to it and re-import properly. The CSV cleaner reads the file as text without deciding anything about types, so it shows you what is actually stored — which is usually enough to establish whether the zeros were ever lost or only ever hidden.

The short version

CSV has no types, so something has to guess, and digits look like numbers. Do not double-click; import and set the column to Text. If you have already opened it, close without saving — the file is probably still fine.

Questions

Why do leading zeros disappear in a CSV?

Because CSV stores no types. Every field is text, and the program opening the file guesses what each one meant. A field of digits looks like a quantity, so it is read as the number 7430 rather than the text 07430 — and a number has no leading zeros to keep. The file on disk still contains the zeros. What you are looking at is the guess, not the data.

Has my file been damaged?

Not by opening it. Open the same file in a plain text editor and the zeros are there, exactly as saved. The damage only becomes real if you save from the spreadsheet — at that point the guess is written back and the original text is gone. This is why the safe move on discovering the problem is to close without saving.

How do I stop Excel removing them?

Do not double-click the file. Use Data → From Text/CSV, and in the import preview set the affected column to Text before loading. That is the only route that tells Excel the answer instead of letting it guess. Changing the cell format after the fact does not help — the zeros were discarded during the import and formatting cannot bring back what was never loaded.

Does an apostrophe fix it?

It fixes the display in Excel and breaks the file for everything else. A leading apostrophe is an Excel convention for "treat this as text", and it is stored in the cell — so exporting to CSV again gives you the apostrophe back as a character on the front of the value, and any other program reads it as part of the data. It is a workaround for a spreadsheet, not a fix for a file.

What about ="07430" in the CSV?

It works in Excel and is the least bad of the tricks, because the formula evaluates to a text value. But it is Excel-specific: a database import, a script or another spreadsheet reads the literal characters ="07430" including the equals sign and the quotes. Use it when you know Excel is the only thing that will ever open the file.

Why did my part number become a date?

The same guess, with a different outcome. A field like 3-4 or 12/07 looks like a date to a spreadsheet, so it becomes one — and once it is a date it is stored as a serial number and displayed by a format, so the original characters are gone. Gene names are the famous casualty: SEPT2 became 2-Sep so reliably that the field renamed its genes rather than keep fighting it.

Can I recover zeros that are already gone?

Only if you know how long the value should be. A postcode column that must be five digits can be padded back from 7430 to 07430 with confidence. A part number of unknown length cannot — 42 might have been 042 or 0042 and nothing in the file says which. Recover from the original export if you still have it, and pad only where the width is a rule rather than a guess.

Is the file uploaded to check it?

No. The CSV tools here read the file in your browser and it never leaves your device. Files with this problem are usually customer lists, payroll exports or order data — the ones worth being careful with.

Tools from this guide

More data tools — all of them running in your browser, none of them uploading a file.