XML to Excel

Getting XML into a spreadsheet without losing anything

Somebody sends you an XML export and asks for it in Excel. It happens constantly with billing files, supplier catalogues, regulatory returns and anything from a system old enough to predate JSON. Excel can technically open XML on its own, and the result is usually either a schema prompt nobody understands or a sheet with one column of raw markup.

The awkward part is deciding what a row is. A document nests, a sheet does not. What this page looks for is the repeating element — the <sim> inside <inventory>, the <item> inside <order> — and makes each one a row. Anything nested below that becomes a dotted column name like device.type, so the structure is still readable across the top rather than flattened into mush.

Attributes get their own columns with an @ prefix. That is not decoration: an XML element name is not allowed to begin with @, so @iccid can never collide with a child element called iccid, and both can appear side by side without one quietly overwriting the other.

The part worth the most is what happens to long numbers. Everything in XML is text, so a 19-digit ICCID arrives here intact — but write it into a numeric cell and Excel rounds it at about 15 significant figures when the file opens, which Microsoft documents plainly and which no amount of care on our side can undo afterwards. Those cells are written as text instead, and the sheet says how many. Short numbers stay numbers, so you can still sum and chart them.

Parsing uses the browser's own DOMParser. Nothing is uploaded, which matters when the file is a customer export.

How to use it

1. Paste or upload your XML – A repeating element anywhere in the document is enough. Well-formed is the only requirement, and a parse error points at the line.
2. Check the preview – The columns you see are the columns the workbook will have. If one you expected is missing, it is missing from every record, not just hidden.
3. Name the sheet if you care – Excel refuses names over 31 characters or containing : \ / ? * [ ] and complains only when the file is opened, so the name is cleaned up before it is written.
4. Read the grey notes – They say which element the rows came from, which attributes became columns, and how many cells were pinned to text to keep their digits.
5. Download it – A genuine .xlsx with column widths and filter dropdowns on the header row, not a CSV wearing a spreadsheet extension.

If the sheet comes out with one row and you expected hundreds, the repeating element is probably nested deeper than the tool guessed — an <items> wrapper inside each <order> rather than at the top. Confirm what the structure actually is with XML to Table, or pull out the branch you want first with the XPath Tester and paste that in instead.

A SIM export, and the column that would have been ruined

Three records with attributes on the element and one nested child. Watch what happens to iccid, which is nineteen digits long — well past the point where a numeric cell in Excel starts dropping them.

<inventory>
  <sim iccid="8944501012345678901" roaming="true">
    <msisdn>447700900112</msisdn>
    <device><type>Pixel 9</type></device>
    <rsrp>-97</rsrp>
  </sim>
  … two more sim elements …
</inventory>

@iccid               @roaming  msisdn        device.type  rsrp
8944501012345678901  true      447700900112  Pixel 9       -97
8944501019876543210  false     447700900187  iPhone 17    -103
8944501055512340987  true      447700900204  Quectel BG95 -112

The two attributes became @iccid and @roaming. A nested
element became device.type. @iccid is a TEXT cell — as a
number Excel opens it as 8944501012345678000.

When this comes up

Someone in finance or operations asked for the data

They are not going to read XML and they should not have to. A workbook with filter dropdowns is the format that lets them answer their own question, and it takes about ten seconds to produce. If they would rather have a comma-separated file, XML to CSV is the same conversion with a plainer output.

Reconciling an export against a system of record

Two files, one spreadsheet each, and a lookup between them beats writing a script for a job you will do once. This is also where the identifier columns matter most — a rounded ICCID or account number silently fails to match, and it looks like missing data rather than a formatting problem.

Checking a supplier feed before it is imported

Sorting a column is the fastest way to spot the empty values, the duplicated identifiers and the one record where a field arrived in a different unit. Doing that in a sheet takes a minute; finding the same problem after the import has run takes considerably longer.

What it handles

• Columns are the union across every record, so a field that only appears from row 40 onwards still gets a column.
• Attributes become @name columns, which cannot collide with element names because XML forbids an element starting with @.
• Nested elements become dotted column names rather than being flattened away.
• <![CDATA[…]]> content is read as text — the XML specification treats it as character data, and a converter that only collects text nodes drops it entirely.
• Text sitting alongside child elements is kept rather than discarded.
• Long identifiers are written as text cells so Excel does not round them, with a count of how many.
• Column widths sized to the content, and filter dropdowns on the header row.
• A sheet name cleaned of the characters Excel rejects, since it refuses them at open time rather than at write time.

Questions worth answering

Why does my identifier column look left-aligned?

Because it is a text cell, and that is deliberate. Excel holds about 15 significant figures in a numeric cell, so a 19-digit ICCID written as a number opens as something ending in zeroes and the original is unrecoverable. Written as text it is exact. Excel would normally flag such a cell with a green triangle reading "Number stored as text"; the file suppresses that warning for the affected range, so you get the digits without the nagging. Short numbers are still written as numbers and still sum and chart normally.

Excel can already open XML. Why use this?

It can, and what you get is either a prompt about creating a schema, a read-only XML table, or a single column of markup — none of which is the sheet you wanted. The bigger issue is that Excel's own import makes its own guesses about types, and that is exactly where long identifiers get quietly rounded. Deciding the cell types deliberately is the whole reason this page exists.

What decides which element becomes a row?

The first repeating element found under the root. <inventory> holding many <sim> elements gives one row per sim. A document with no repetition at all becomes a single row, which is correct but rarely what someone wants — if that happens, the list you were after is probably nested deeper, and the XPath Tester will show you where.

What happens to namespaces?

Prefixes are kept as part of the column name, so <net:rsrp> becomes the column net:rsrp. Nothing is stripped, because two elements with the same local name in different namespaces are genuinely different fields and merging them would be a quiet data error. It does make for longer headers on SOAP-derived documents, which is the honest trade.

Is anything sent to a server?

No. Parsing and the workbook are both produced in the browser, so the document never leaves your machine. The reverse trip is available too: Excel to JSON reads an .xlsx back, though be aware that direction genuinely can lose precision, because by then Excel has already stored the value as a double.

Related tools

Further reading

• SheetJS documentation – The library that writes the workbook, and what it does and does not support.
• Excel specifications and limits – Row and column ceilings, and the 15-digit precision limit behind the text cells.