XML to Excel Converter

The XML that ends up needing a spreadsheet

Nobody converts XML for the pleasure of it. It happens because a system that only speaks XML has handed over something a person now has to sort, filter, or forward. Five kinds of file account for almost all of it:

• Vendor and marketplace feeds. Product catalogues from a wholesaler or a shopping channel arrive with attributes on every item and a shipping block underneath. Merchandising wants columns.
• Finance and payroll exports. Bank statements in ISO 20022, older payroll dumps, tax filings. Reconciliation happens in a workbook, never in a tree view.
• Saved SOAP responses. Line forty captured responses up next to each other and you can finally see which optional fields the vendor populates and which are always empty.
• Published reference data. Regulatory filings, transport timetables, survey extracts. XML is what the publisher ships; Excel is where the questions get answered.
• Configuration under review. Two hundred entries in a build file or a resource bundle become two hundred rows, and the duplicates and gaps stop hiding.

The hard part is never the conversion. It is what happens to the nesting, which is what most of this page is about.

What the nesting turns into

A spreadsheet needs to know what one row is, and XML never says. The rule applied here is short: group the root's direct children by tag name, and the largest group is the records. A feed carrying one generator element beside 3,000 entry elements gives 3,000 rows, with the generator left out.

• Child elements become columns named with dots. A billing block inside each record produces billing.street and billing.zip.
• The dots run three levels below the record element. Past that, the branch is written into one cell as its own text and the widget prints a note counting how many places that happened in.
• An attribute takes the name of whatever it hangs off. currency on a nested total becomes total.currency, while an attribute on the record element itself is just currency.
• Only the root's own children are counted. If your records sit under response, then body, then rows, nothing repeats at the top level, so copy the inner fragment into the paste tab instead of feeding it the whole envelope.
• Namespace prefixes are removed before column names are built, so g:price becomes a column called price.

Documents that resist becoming a sheet

• Mixed content loses the loose words. Given <note id="1">see <ref>A4</ref> for detail</note> you get a ref column holding A4, and the text around it is gone. Once an element has child elements it is read through those children only. Prose-shaped XML is the wrong input for a spreadsheet, and this is where that shows.
• Two namespaces can share one column. Prefixes are stripped for readability, so a document that uses both dc:title and atom:title puts them in a single title column, and the one read later wins the cell.
• A single record still converts, with a warning. If the root has one child, you get a one-row workbook and a note saying the structure may not be tabular. That nearly always means the real records live a level deeper.
• Repeated children inside a record collapse. Three tag elements inside the same item write into one tag column and the last one is what you keep. Splitting those into separate rows is a job for the full editor.
• There is no copy button here. A workbook is binary, so this page offers a download and nothing else. To paste cells straight into a sheet that is already open, use the XML to table tool instead.
• 100 MB is the ceiling. No row cap and no daily quota below that. Above it the widget hands you to the full editor rather than pulling the whole document into memory at once.