Convert nested XML into predictable CSV columns.
Turn hierarchical XML exports into a table without writing XPath or flattening scripts. XMLSlice detects repeating records and keeps nested paths visible while you choose columns.
Open the private converter ↗- Nested paths
- Preserved with /
- Record model
- One element per row
- Processing
- Local browser
The reliable conversion model
To convert nested XML to CSV, choose the element that represents one record, then map descendant values to slash-separated columns. XMLSlice performs both steps locally and shows a preview before exporting the complete CSV.
Understand the structure
What matters before conversion
Choose the row boundary first
A nested document can contain orders, customers, and line items at different depths. Selecting the repeating order element establishes what one CSV row means and prevents unrelated lists from being mixed.
Keep hierarchy in column names
A value such as customer/name becomes a readable CSV column instead of losing its context as name. This also distinguishes it from fields such as shipping/name in the same record.
Handle repeated leaf values deliberately
When a record contains several values for the same leaf path, XMLSlice joins them with a pipe separator. Separate child tables should be exported as their own record group when one-to-many analysis is required.
Practical workflow
Convert in four clear steps
- 01
Open the XML file
Drop the local file into XMLSlice. The structure is analyzed in a background worker and the source stays on the device.
- 02
Select the repeating element
Choose the candidate whose count and path match the records you expect, such as catalog/products/product.
- 03
Choose descendant fields
Keep useful paths such as customer/name, address/city, and totals/tax while removing fields that do not belong in the table.
- 04
Preview and export
Verify the first rows, then export a spreadsheet-compatible UTF-8 CSV or save the mapping as a reusable recipe.
Worked example
Nested customer data example
The order element is the record boundary. Descendant names retain enough context to become unambiguous columns.
<orders>
<order id="1048">
<customer><name>Amelia Stone</name></customer>
<totals><net>100.00</net><tax>20.00</tax></totals>
</order>
<order id="1049">
<customer><name>Jonas Klein</name></customer>
<totals><net>75.00</net><tax>15.00</tax></totals>
</order>
</orders>'@id,customer/name,totals/net,totals/tax
1048,Amelia Stone,100.00,20.00
1049,Jonas Klein,75.00,15.00@id, customer/name, totals/net, totals/taxThe leading apostrophe on the raw @id header reduces spreadsheet formula risk; spreadsheet applications normally display the label as @id.
Quality control
Conversion checklist
- ✓Confirm the selected element count matches the expected row count.
- ✓Keep full nested paths when similarly named fields appear in different branches.
- ✓Export child lists separately when they need one row per child.
- ✓Review missing values in the preview before importing the CSV elsewhere.
Questions and answers
Nested XML FAQ
Can nested XML be represented in CSV without losing information?
Scalar descendant values fit naturally into columns. One-to-many child structures require a deliberate choice: join repeated leaves in one cell or export the child element as a separate table.
Does XMLSlice require an XML schema or XPath?
No. It discovers repeating paths and observed fields directly from the document stream.
How are two nested fields with the same name handled?
Their parent paths remain in the column labels, so customer/name and shipping/name stay distinct.