CSV ⇄ Excel Safe Converter
The double-click way of opening a CSV in a spreadsheet destroys data silently: leading zeros
vanish, long barcodes become 8.71E+12, and MAR1 becomes a date. This
converter produces an .xlsx in which every identifier column is already typed as text — so the
spreadsheet never gets the chance. It converts back to clean CSV too, with every liberty
disclosed instead of taken silently.
🔒 Your data never leaves your browser. Parsing, protection analysis and the xlsx packaging all run on your own machine.
Drop a CSV or .xlsx file here
.csv / .tsv → safe .xlsx · .xlsx → clean CSV · direction is detected from the file itself
Why Excel eats your barcodes, and what "safe" means here
A CSV file has no types — every cell is text. The moment a spreadsheet imports one, it guesses
a type for each cell, and the guesses are destructive: 00123 is "the number 123",
so the zeros are deleted; 4006381333931 is a big number, so it is displayed as
4.00638E+12 and — past 15 digits — the tail is replaced with zeros in the
stored value itself; 1-Mar is "obviously" a date. None of this asks
permission, and re-saving writes the damage back into the file.
An .xlsx file, unlike a CSV, does carry types. This converter uses that: columns that hold identifiers — leading-zero codes, GTIN/EAN/UPC columns (recognised by their check digits), postal codes, phone numbers, date-shaped text — are detected and written as text cells, which spreadsheets display verbatim and never reinterpret. Ordinary numbers (prices, quantities) stay real numbers, so your sheet still sorts and sums. Every protected column is listed in the result with the rule that fired and example values — you can check its work.
Coming back: xlsx → CSV without new damage
The reverse direction is just as careful. Numbers are never written in scientific notation — values Excel stored in exponent form are expanded exactly, by string arithmetic, not floating point. Date cells become unambiguous ISO 8601 text, using the epoch the workbook itself declares (workbooks from old Mac Excel count from 1904; the same serial number is 1,462 days apart between the two systems). Formulas contribute their last calculated value, merged cells flatten with the value in the top-left corner — and each of these liberties is counted and disclosed in the result, because a conversion that changes things quietly is how the damage started in the first place.
What this tool refuses to do
If your CSV already contains Excel damage — 8.71E+12 where a barcode used to be —
converting it cannot bring the digits back; they are not in the file. The tool warns you and
points to the Excel damage diagnostic for a
cell-by-cell recoverability verdict, rather than pretending a clean-looking .xlsx fixed
anything. Legacy .xls and password-protected workbooks are refused with an
explanation, not mis-parsed.
Column protections (7 rules)
PROT-001Leading zeros protected
The column contains all-digit values that start with 0 (UPC-12 written with its leading zero, EAN-8, account codes). Opened as numbers, spreadsheets drop the zeros silently and the identifiers stop scanning. The whole column is written as text cells.
PROT-002Long digit strings protected
The column contains digit runs of 12 or more characters. Excel keeps only 15 significant digits and switches to scientific notation display, so GTIN-13s and account numbers get mangled (…E+12) or zero-padded at the tail. The whole column is written as text cells.
PROT-003GTIN / EAN / UPC column protected
Most values in this column are 8/12/13/14-digit codes whose check digits verify — this is a barcode column, and barcodes are identifiers, not quantities. Written as text so no digit is ever reformatted.
Source: Own engineering rule, derived from documented spreadsheet number handling and the damage signatures catalogued by the Excel damage diagnostic on this site. Each trigger has its own regression fixtures.
PROT-004Phone numbers protected
Values shaped like international phone numbers (+ prefix). As numbers they lose the +, the leading zeros of area codes, and any formatting. Written as text cells.
Source: Own engineering rule, derived from documented spreadsheet number handling and the damage signatures catalogued by the Excel damage diagnostic on this site. Each trigger has its own regression fixtures.
PROT-005Date-like text kept as text
Values that look like dates (01/02/2026, 1-Mar). Converting them to spreadsheet date serials silently commits to one reading of an ambiguous format and changes what is stored. The original text is preserved; nothing is reinterpreted.
Source: Own engineering rule, derived from documented spreadsheet number handling and the damage signatures catalogued by the Excel damage diagnostic on this site. Each trigger has its own regression fixtures.
PROT-006Postal codes protected
The column header names a postal/ZIP code and the values are code-shaped. US ZIP codes starting with 0 (all of New England) are the classic casualty — 07030 becomes 7030. Written as text cells.
PROT-007Formula-like content neutralised as text
Values start with = or @ (or their full-width variants). In a CSV opened by a spreadsheet these execute as formulas (CSV injection); written as xlsx text cells they are inert literal text. Nothing is removed from the value — it is stored exactly as given, as text.
Source: https://owasp.org/www-community/attacks/CSV_Injection
Conversion disclosures (9 rules)
XLC-W01Source already carries Excel damage
Cells in the source CSV match known damage signatures (scientific notation like 8.71E+12, suspected lost leading zeros). Conversion stores what the file actually contains — it cannot restore digits that are no longer there. Unrecoverable cells need re-export from the original system.
Fix: Run the column through the Excel damage diagnostic to see exactly what is recoverable, then re-export the damaged columns from the source system.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-W02Delimiter was ambiguous
More than one separator produces a plausible parse of this file. The conversion used the best-scoring candidate; if columns look shifted, the guess was wrong.
Fix: Check the column count in the result, or re-export the CSV with an unambiguous separator.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-R03Formulas exported as their last calculated values
The workbook contains formulas. A CSV has no formula concept, so each formula cell contributes the value the spreadsheet last calculated for it. If the workbook was saved without recalculating, that cached value can be stale.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-R04Merged cells flattened
Merged ranges keep their value in the top-left cell only; the other cells of the range come out empty. That is how the data is actually stored — nothing was invented to fill the gaps.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-R05Date cells rendered as ISO text
Date-formatted cells are stored as day serial numbers. They were rendered as unambiguous ISO 8601 text using the epoch the workbook itself declares (1900, or the legacy Mac 1904 system — the same serial differs by 1,462 days between the two).
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-R06Embedded objects not carried over
Images, charts or embedded documents exist in the workbook. CSV is plain text; these objects are counted here so their absence in the output is a known fact, not a silent loss.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-E07Not a readable .xlsx package
The file is not an xlsx zip container. Legacy .xls and password-protected workbooks use a different (OLE) container and are deliberately out of scope — a wrong-guess parse of those formats would produce confidently wrong data.
Fix: Open the file in a spreadsheet application and save it as .xlsx (unencrypted), then convert.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
XLC-W08Output contains values Excel would damage again
The exported CSV contains leading-zero or 12+ digit values. Opened by double-click in a spreadsheet, those get damaged all over again — the CSV itself is correct, the risk is in how it gets opened next.
Fix: Import the CSV via the spreadsheet's text-import path with those columns set to Text — or keep the data in .xlsx.
XLC-E09Input is empty or not tabular
The input has no parseable rows (empty file, or no candidate separator produces a consistent column count). Nothing was converted.
Source: Own engineering rule. The conversion pipeline documents every liberty it takes; anything it cannot carry over is counted and disclosed rather than silently dropped.
Scope, honestly: data tables only. Formulas are exported as their cached values, styling is
not preserved, pivot tables and charts do not travel, and .xls (the pre-2007 binary format)
is out of scope. The same engine powers the convert_csv_to_xlsx and
convert_xlsx_to_csv tools in the yaktool MCP server.
One disclosure about the .xlsx we write: its file properties record
Application: yaktool.com, the same way Excel records "Microsoft Excel" and every
other generator names itself. That is metadata only — no cell is ever touched,
and CSV output gets nothing added at all.