Convert XML to CSV

Pick the repeating record, fold attributes alongside elements, handle namespaces, get a clean CSV. No upload, no install, no size cap.

When you'd convert XML to CSV

  • Legacy data feeds. Plenty of older systems publish data as XML: SOAP responses, exported configurations, log archives. CSV is the path to anything else that wants to consume them.
  • Government and public-sector open data. A surprising amount of public data is shipped as XML. Converting to CSV is the first step to using it in a spreadsheet or warehouse.
  • Product feeds in e-commerce. Marketplaces (Amazon, Google Merchant) often expose catalogues as XML. Converting to CSV lets you diff, edit in bulk, and re-upload.
  • RSS/Atom-style content extraction. When you want to pull article metadata out of a feed and into a sheet for tracking, XML to CSV is the natural pipe.
  • Loading XML into BI tools. Most BI tools ingest CSV or Parquet, not XML. Convert once, load many.

Worked example: attributes folded alongside elements

A record-oriented XML feed:

<orders>
  <order id="1001" currency="USD">
    <customer>Acme Corp</customer>
    <quantity>3</quantity>
  </order>
  <order id="1002" currency="EUR">
    <customer>Beta Inc</customer>
    <quantity>1</quantity>
  </order>
</orders>

With the record path set to order, the CSV output folds attributes (prefixed with @) and child elements into a flat row:

@id,@currency,customer,quantity
1001,USD,Acme Corp,3
1002,EUR,Beta Inc,1

If you'd rather strip the @ prefix or rename the columns, do that in the schema panel before exporting.

Format-specific gotchas

  • Pick the right record element. XML doesn't have a built-in concept of "row." Whatever element repeats becomes one row. ExploreMyData guesses, but for deeply nested feeds you may need to point it at the right level explicitly.
  • Attributes vs child elements. CSV columns can come from either. We prefix attributes with @ to keep them distinct. If an attribute and a child element share a name, the @ prefix prevents collision.
  • Namespaces. Elements with prefixes (ns:product) are preserved as ns:product column names. If your downstream tool dislikes colons, strip prefixes during export.
  • Repeated child elements. If <order> contains multiple <tag> children, you choose: explode the parent into one row per tag, or stringify the tags into a single cell. Default is explode.
  • Mixed content. Some XML mixes text and child elements inside one element. CSV can't represent that cleanly. We concatenate the text fragments with a marker separator and warn you when this happens.
  • CDATA and entities. CDATA blocks and entity references (&amp;, &lt;) are decoded properly. The CSV output is plain text with standard quoting.

How this differs from the alternatives

  • vs Online XML Tools (xml-to-csv). Clean UI, no ads, but offers no record-path or XPath selector, so it works best on already-flat XML. ExploreMyData lets you pick the repeating element explicitly, which matters for deeply nested feeds.
  • vs ConvertCSV (xml-to-csv). Powerful, with XPath-style starting-node selection and pivot output. The UI is dated and dense with checkboxes and donation prompts; large XML can stall the page. ExploreMyData runs the parse via DuckDB-WASM with a less cluttered interface.
  • vs TableConvert (xml-to-csv). Modern UI, browser-based, but caps the free tier at 10 MB. ExploreMyData has no fixed cap.
  • vs xmllint + xsltproc. The standard libxml2 toolchain. Powerful, but you have to write an XSLT stylesheet to project the XML into CSV, which is a real learning curve. ExploreMyData covers the typical case point-and-click.
  • vs pandas + lxml (pd.read_xml). One-liner for relatively flat XML. Nested or attribute-mixed content needs a custom XSLT stylesheet or manual flattening, plus Python and lxml installed. ExploreMyData handles attributes and one level of nesting without code.

Frequently Asked Questions

How do I tell the converter which element is one row?

ExploreMyData previews the XML structure and lets you pick the repeating element that should map to one CSV row. For an XML feed of <product> records, you'd select <product>. The detection guesses by default, but you can override.

What about XML attributes vs child elements?

Both become columns. Attributes are prefixed with @ by default (e.g., @id) so they don't collide with child elements that have the same name. You can change the prefix or merge attributes and elements into a single namespace.

Does it handle namespaces?

Yes. Namespace-prefixed elements are preserved as columns named ns:element by default. If a recipient doesn't expect prefixes, you can strip them in the export dialog.

What happens with repeated child elements?

Repeated elements become a list. ExploreMyData asks whether you'd rather explode the parent into multiple rows (one per child) or keep the children as a stringified list in one cell. Default is explode for top-level repeated structures.

Are CDATA sections handled?

Yes. CDATA content is treated as the element's text content, with quoting and escaping handled automatically when written to CSV.

Is there a size limit?

No fixed limit. We stream the XML parser, so multi-hundred-MB feeds work in the browser. Limits depend on your browser's available memory.

Convert your XML to CSV

No sign-up, no upload. Pick a record path, fold attributes, get a clean tabular file.

Open the converter