Converting CSV and XML to Excel Without Losing Data

The quickest way to open a CSV in Excel is to double-click it, and that's also the quickest way to damage it. Excel guesses a type for every cell as it opens the file, and its guesses break exactly the columns people care about: PIN codes, account numbers, order IDs, and anything with non-English characters. Here's what goes wrong, what the conversion should do instead, and how XML fits the same picture.

What double-clicking a CSV does to your data

Take this line from a customer export:

pin,account_no,order_id,amount,date,note
004102,123456789012,12345678901234567890,"1,200",2026-03-04,₹ paid

Opened directly in Excel:

• 004102 becomes 4102. The leading zeros are gone for good, and saving the file writes the damaged value back.
• 123456789012 shows as 1.23457E+11. The value itself is intact, but the display hides it.
• 12345678901234567890 becomes 12345678901234500000. Excel stores numbers to 15 significant digits, so the last five digits are replaced with zeros.
• ₹ paid may show up as ₹ paid. On Windows, Excel reads a CSV without a byte-order mark using the system's legacy code page instead of UTF-8.

What a careful conversion does instead

The CSV ⇄ Excel Converter reads the file as UTF-8 and decides each cell's type with explicit rules. For the same line:

Two things to know after opening the result:

• A 12-digit number still displays as 1.23457E+11 in a narrow column with Excel's default "General" format. The digits are all there; format the column as Number with 0 decimal places to see them.
• Cells kept as text show Excel's small green triangle ("number stored as text"). That's expected for codes, which you don't want summed anyway.

The converter detects the delimiter automatically, so semicolon-separated exports (common from European-locale systems) and tab-separated files work without any setting. Quoted fields containing commas or line breaks stay in one cell. Uploaded files and pasted text follow the same rules, and uploads up to 200MB are processed in the background so the tab stays responsive.

Excel back to CSV

Going the other way, the converter reads the first sheet of the workbook and writes each cell as you'd see it in Excel, with three deliberate exceptions:

• Dates come out as `yyyy-mm-dd`. Excel's built-in date format would otherwise be written as 9/24/26, whatever your locale. Outside the US month/day convention that's ambiguous, and the two-digit year adds a second guess.
• Unformatted long numbers keep every digit. You get 123456789012, not 1.23457E+11.
• Formatted numbers keep their formatting. A cell shown as 1,200.50 is written as "1,200.50", quoted because of the comma. If the next system needs raw numbers, set those columns to General in Excel before converting.

Formulas are written as the value Excel last calculated and saved. The formula itself isn't included.

XML to Excel: finding the records

XML exports usually hold a list of similar records inside a wrapper:

<catalog>
  <product id="p1">
    <name>Desk Lamp</name>
    <price currency="INR">1499</price>
    <sku>00731</sku>
  </product>
  <product id="p2">
    <name>Chair</name>
    <price currency="INR">4999</price>
    <sku>00732</sku>
  </product>
</catalog>

The XML ⇄ Excel Converter looks for the first element that repeats (<product> here) and makes one row per occurrence:

• Attributes become columns prefixed with @_.
• Nested elements become dotted column names.
• An element that has both text and attributes (<price currency="INR">) splits into a .#text column and one column per attribute.
• Codes such as 00731 keep their leading zeros, and values like 0x1F or 2E10 stay text rather than being read as hex or scientific notation.

The column names look unusual, but they're what makes the reverse direction work. Converting that sheet back to XML rebuilds <price currency="INR">1499</price> and the id attribute exactly, with each row becoming a <record> inside <root>.

One limitation: the converter needs a repeating element. A file with a single <product> has no list to turn into rows, so the tool reports that it couldn't find a repeating list of records. Converting it to JSON with the XML ⇄ JSON Converter works for that case.

Check the XML before converting

If an XML file comes from another system, run it through the XML / XSD Validator first. It reports the line and column where a document stops being well-formed, such as an unclosed tag or a bare & that should be &. If you paste the XSD as well, it flags any element names the schema doesn't declare. That's a name check only: data types, element order and occurrence counts aren't validated in the browser. For CSV output instead of Excel, the XML ⇄ CSV Converter uses the same record detection and column naming.