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 — a parser has no way to know <rsrp>-97</rsrp> was meant as a number and <iccid>8944501012345678901</iccid> was not, so every value from this page reaches the workbook as a string. Writing a 19-digit ICCID into a numeric cell is what loses it: Excel rounds anything past about 15 significant figures the moment the file opens, which Microsoft documents plainly, and no amount of care on our side can undo that afterwards. Leaving every value as text sidesteps the whole problem rather than trying to guess which strings were "really" numbers — a guess that would also turn a phone number's leading zero into a silently dropped digit. The sheet tells you how many cells were long enough that a numeric type would have rounded 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 8944501012345679000.

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 every value from this page is a text cell, and that is deliberate — XML has no type system, so nothing here tries to guess which leaves were "really" numbers. For most columns that is invisible; for a 19-digit ICCID it is the fix, because Excel holds about 15 significant figures in a numeric cell and would open the number ending in zeroes with the original unrecoverable. Excel would normally flag a number-shaped text cell with a green triangle reading "Number stored as text"; the file suppresses that warning for the whole sheet, so you get the digits without the nagging. If you need a column to sum or chart, select it and convert it with Excel's own Convert to Number — safe for a column of short values, and a reminder to leave alone for anything long enough to need this page in the first place.

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.