A 16-digit order ID opens in Excel as 1.23457E+15 — and if anyone saves, the last digit becomes a zero, permanently. This is the most destructive of Excel's CSV habits because the damage is silent and irreversible. Here's the mechanics and the protection.
Excel stores numbers as 64-bit floats, which hold 15 significant digits. A 16-digit ID doesn't fit: the display switches to scientific notation (1.23457E+15) and the 16th digit onward is rounded to zero internally.
Like the leading-zeros problem, the root cause is type inference — an all-digit field reads as a number. Unlike leading zeros, the loss can be unrecoverable: there's no rule that reconstructs a rounded digit.
If you haven't saved from Excel, the CSV is intact — the notation is only display. Check the raw values in a non-coercing viewer: real IDs end in varied digits.
A damaged file shows the tell: long IDs all ending in 0 (…230, …450, …780). If you see that pattern across 16+ digit values, the file was saved through Excel and the source system is your only recovery.
Data → From Text/CSV, set the ID column's type to Text before loading. Text columns keep every digit and never switch to scientific notation.
This must happen at import — converting the column to Text after opening is too late; the rounding already occurred in memory.
When the file will pass through other people's Excels, convert it to .xlsx with ID columns typed as text. Their double-click can't hurt it.
The converter recognizes long-digit ID columns and writes them as text cells automatically.
If you control the pipeline, the cleanest fix is upstream: export IDs quoted ("4111111111111111") and parse them as strings in code (dtype=str in pandas, VARCHAR in SQL). An ID is a name, not a quantity — nothing should ever do math on it.
Every tool on this site treats ID-role columns as text — conversions to JSON, SQL or Parquet keep them as strings.
Not from the damaged file — the digits are mathematically gone. Re-export from the source system; if a different column (email, timestamp) uniquely identifies rows, a join can re-attach correct IDs from a clean export.
Anything up to 15 digits fits in a float exactly, so ordinary quantities never hit this. The problem is exclusive to long digit strings — which are almost always identifiers.
No — CSV is text and holds any length. The limit belongs to the program parsing it as a float.
Anything parsing to 64-bit floats can — including JavaScript's Number and some BI imports. Tools that keep values as strings (like the ones here) don't.