Put the Leading Zeros Back in Your CSV Columns

Excel opened your file, decided 00501 was just the number 501, and threw the zeros away. Paste or drop the CSV below, tick the columns that lost zeros, set the correct width — and download the file whole again.

✔ 100% free ✔ No signup ✔ Files never leave your browser ✔ Works offline
Drop your CSV file here or click to choose a file
…or paste the data straight into the box below

Or paste CSV data:

🔒 Everything runs locally in your browser. Your data is never uploaded, stored, or seen by anyone.

Why Excel deletes leading zeros in the first place

A CSV file is plain text — nothing in it says "the zip column is text, keep it exactly as written." When you double-click a CSV, Excel parses every cell and guesses its type. A cell containing only digits becomes a number, and to a number parser 00501 and 501 are the same value. Excel stores 501, and the zeros are gone before the spreadsheet finishes opening — no warning, no green triangle, nothing to undo.

The surprise is that this isn't a display glitch: Excel never stored the zeros at all. The moment the file is saved (even clicking "Keep Current Format" on the prompt while closing), the stripped values are written back into the CSV, and that copy is permanently damaged.

The usual victims

How the repair works: pick columns, set widths

Paste your data or drop the file, then click Analyze my CSV. The "Restore leading zeros" repair is pre-selected on this page, and a table appears listing every column in your file. Tick the ones that lost zeros and type the width each value should be padded to:

Code typeWidthExample repair
US ZIP code550100501
GTIN-8 / EAN-88715890607158906
ABA routing number911000015011000015
UPC-A (GTIN-12)1271589000123071589000123
EAN-13133600020000120360002000012

Padding uses plain string operations — no number parsing anywhere, so a 13-digit EAN can't be re-damaged in transit. Two safety rules apply: only cells made entirely of digits are touched (a ZIP+4 like 08544-0291 is left alone), and values already at or above the target width never change. The preview highlights each repaired cell for a spot-check before you download.

You supply the width because the file no longer records how many zeros were removed — 501 could have been 0501 or 00501. Fixed-width code systems make the repair deterministic: a US ZIP is always five digits, an EAN-13 always thirteen.

Zeros missing right now?

Scroll back up, paste the file, tick the damaged columns and set the widths — the repaired CSV downloads in seconds, and nothing leaves your machine.

Repair my CSV now

Prevention: import as Text — and why the 00000 format trick isn't enough

Never double-click a CSV that contains code columns. In modern Excel, use Data → From Text/CSV, click Transform Data, and set the ZIP/SKU column type to Text before loading. In older versions, rename the file to .txt, open it, and in step 3 of the Text Import Wizard mark each code column as Text. Either way Excel stores the literal string 00501, and the zeros are safe.

You will also see the advice to apply Format Cells → Custom → 00000. Know what that actually does: it makes 501 display as 00501, but the cell still holds the number 501 — the format is cosmetic. Formulas compare stored values (=A2="00501" returns FALSE), a VLOOKUP against a real text ZIP column finds nothing, and anything that reads values instead of display strings — Power Query merges, database connectors, copy-paste — receives the broken three-digit code. Even when a CSV export writes out the padded display string, the next double-click strips the zeros all over again. Masking the symptom is not storing the right data; import as Text and the problem is actually gone.

Where this bites hardest

Shipping teams meet it first: label APIs and USPS address validation reject a four-digit ZIP outright, so every order bound for New Jersey, Massachusetts, or Puerto Rico stalls until someone re-keys the codes. Marketplace sellers meet it as silent SKU drift — the feed says 71589, the catalog says 0071589, and the upload either errors with "SKU not found" or quietly creates a duplicate listing that splits inventory. Payroll and banking imports fail checksum validation when a routing number arrives a digit short.

For a full walkthrough of the Text-import steps in every Excel version, read the companion guide: why leading zeros disappear from CSV files — and how to stop it.

Excel rarely stops at one column. If barcodes in the same file came out as 8.85909E+11, run the scientific notation fixer; if accented names turned into é garbage, the broken characters fixer reverses the encoding damage. Both use the same paste-and-download flow.

Frequently asked questions

How does the tool know how many zeros each value lost?

It doesn't guess — you tell it. The CSV no longer contains any trace of the removed zeros, so the tool asks for the correct total width and pads every shorter value up to it. That works because real code systems are fixed-width: US ZIPs are 5 digits, GTIN-8 is 8, EAN-13 is 13, ABA routing numbers are 9. Values already at or above the width are never changed.

What happens to mixed values like ZIP+4 (08544-0291) or SKUs with letters?

They're skipped. The padder only touches cells made entirely of digits, so 08544-0291, A-1001, or 501B pass through unchanged. If your ZIP+4 column stores nine plain digits without the hyphen, set the width to 9 instead of 5.

Will the zeros survive the next time the file is opened in Excel?

It depends on how you save and reopen it. Tick Excel-safe export and each code is written as ="00501", which Excel reads as text even on a double-click, so the zeros survive. Without that option, double-clicking the plain CSV strips the zeros again — open it via Data → From Text/CSV with the code columns set to Text, or keep the file out of Excel. The UTF-8 BOM helps Excel display special characters correctly; it does not prevent zero-stripping.