Convert XML to CSV
XML to CSV is for the moment when a hierarchical document needs to become a table that a spreadsheet, reporting tool, or batch import can read. The built-in transform looks for ordinary repeated record-like elements, turns those records into rows, and flattens nested values into column paths that can be scanned or filtered. Attributes are treated as data rather than decoration, which helps preserve identifiers, status fields, units, and other metadata attached to a record. CSV is deliberately simpler than XML, so the output is not a perfect mirror of an arbitrary document. Deeply uneven branches, mixed text and child elements, repeated fields inside one record, namespaces, and order-sensitive content can produce columns that need review. This is a pure-code conversion of the XML file you upload. It does not run an XSLT stylesheet, query a database, fetch external entities, or infer business rules such as totals and date formats. Use it for ordinary repeated data, then inspect headers and a few rows before sharing or loading the CSV into a system that expects a fixed schema.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your XML file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- Repeated XML records emitted as CSV rows
- Nested fields flattened into readable column paths
- Ordinary attributes included as record data
- Pure-code export with clear limits for irregular XML
How to use XML to CSV
- 1
Upload the source XML
Choose the XML file that contains the repeating records. The conversion reads the supplied document only and does not visit a URL, retrieve an external DTD, or download linked resources that the file happens to mention.
- 2
Identify the row shape
The transform finds ordinary repeated record-like elements and flattens their nested values and attributes into columns. Decide which element should represent one row by inspecting the first output, especially when the document contains several levels of repetition.
- 3
Validate headers and rows
Open the CSV in a text editor or spreadsheet and check delimiters, headers, empty cells, repeated values, and long fields. Confirm that the resulting row shape matches the destination import before treating the file as a complete dataset.
How it works
CSV needs a row and column decision that XML does not require. The converter therefore starts with ordinary repetition: a group of sibling elements that looks like the same kind of record can become multiple rows. The record's direct values supply straightforward columns, while child elements are flattened into named fields or paths. Attributes are read as part of the record so that an id, code, state, or unit does not vanish simply because it was written inside an opening tag.
Flattening is useful precisely because it is a compromise. A spreadsheet can sort a price column, but it cannot naturally express a customer containing an address containing several delivery notes. A nested value can be made readable as a path, and a repeated child can be represented by a convention, but the table still needs a stable interpretation. If one parent contains three line items, decide whether the row is the parent order, each line, or a denormalized combination. No generic converter can know the business answer from XML syntax alone.
The transform does not use an XSLT stylesheet or an external schema to invent that answer. It works on the file provided, does not fetch remote entities, and does not calculate or normalize values. Quoting and delimiters are handled for the generated CSV, but a CSV consumer still needs to agree on encoding, header names, empty values, and date conventions. Open the output as plain text as well as in a spreadsheet when those details matter.
When you'd use this
Use XML to CSV for a quick inventory export, a supplier feed review, a flat report, or a one-time handoff to someone who works in spreadsheet software. It is especially helpful for discovering which fields a feed actually contains before designing a database table. A few representative rows can reveal missing values, optional branches, and attributes that an initial mapping overlooked.
Do not treat every generated CSV as a finished relational model. Preserve the XML when repeated nested data, signatures, namespace identity, comments, or document order carries meaning. For scheduled imports, write a small validation step that checks required headers, row counts, identifiers, and the intended repetition level. That turns a convenient export into a controlled handoff instead of a silent data reshaping.
Worked examples
For a catalog where every product has one name and price, the result is comfortably tabular: one product
per row, with sku and active columns alongside the visible fields. An order feed is more revealing. If
each order contains several line elements, a report may want one row per order while an accounting import
may want one row per line. Keep an order identifier in either design so the relationship survives flattening.
A useful acceptance check is to count records before and after conversion, then inspect one record with an optional nested branch and one with two repeated children. If a spreadsheet view hides a second value in a cell or makes two levels look like one, stop and choose a schema deliberately. CSV is excellent for a clear flat slice; it is not a replacement for the original hierarchy.
Examples
Product records for a spreadsheet review
A buyer can sort by price or filter the active flag without learning the source XML vocabulary. The attributes matter here because dropping sku would make the spreadsheet visually pleasant but unusable for matching a later stock update.
Orders flattened for an import check
This exposes an important review point: one order with several lines does not fit every flat table without a choice. Inspect whether rows represent orders or lines, and split the output or add an explicit key when the destination needs both levels without losing relationships.
Frequently asked questions
How does XML to CSV decide which elements become rows?
The built-in transform is intended for ordinary XML with repeated record-like elements. Those repeated siblings provide the natural row candidates, while their child values and attributes become fields. Documents with several nested repeating levels are inherently ambiguous, so inspect the result and confirm whether the rows represent products, orders, line items, or another level before importing it.
Are nested XML values and attributes lost in CSV?
They are flattened rather than represented as a tree. Nested values become column paths or fields, and ordinary attributes remain available as data columns where the record shape supports them. CSV cannot preserve arbitrary depth, element order, or multiple values in one cell without a convention, so review repeated child fields and keep the original XML for a lossless source record.
Can this converter apply an XSLT stylesheet or clean my data?
No. It is a pure-code structural export, not an XSLT engine or a data-quality pipeline. It does not execute templates, query external sources, calculate totals, normalize dates, validate an XSD, or choose business-specific joins. Use the CSV as a practical starting table and perform deliberate cleaning, validation, and schema mapping in the system that owns those rules.