XML → CSV 转换器，免费

Why XML-to-CSV Conversion Comes Up So Often

XML is verbose and hierarchical; CSV is flat and dense. A lot of useful real-world data lives in XML, sitemap.xml, RSS / Atom feeds, WordPress export files, Apple plist configs, Maven pom.xml dependency lists, GPS tracks (GPX), Google Earth placemarks (KML), bank statement formats (CAMT.053, MT940 in XML form), e-commerce product feeds, healthcare HL7 v3, financial reports in XBRL, sheet music in MusicXML, and almost none of it can be analysed without first being flattened into rows. Excel, Google Sheets, SQL LOAD DATA, Pandas, R, Tableau, Power BI all consume CSV out of the box; getting your XML into one of those tools means converting first.

The Fundamental Mismatch

XML allows arbitrary nesting; CSV is two-dimensional. There is no general-purpose lossless XML→CSV mapping. Any converter has to make assumptions about which level of the tree represents "rows" and how to handle deeper nesting. The two common shapes:

• Repeating-record format (the easy case). A root element containing many children, each with the same shape. <catalog><book>…</book><book>…</book></catalog>. Each <book> becomes a row; its leaf elements become columns. This is what the converter looks for and handles cleanly.
• Mixed-content document format. Flowing text with embedded markup, like XHTML or DocBook. There's no clean CSV mapping for this, usually serialised as a single string cell or rejected.

The tool auto-detects the repeating element by finding the most frequent direct child of the root, which is correct for ~90% of real XML feeds. If your XML doesn't fit that pattern, pre-process it first with a quick XPath script or hand-edit it down to a repeating-record shape.

Common XML Feeds That Convert Well

• sitemap.xml: every <url> entry becomes a row with loc, lastmod, changefreq, priority columns. Useful for SEO audits and content inventories.
• RSS / Atom feeds: each <item> or <entry> becomes a row. Useful for content marketing analysis or migrating to a different platform.
• WordPress export XML (WXR): <item> tags for posts, pages, attachments. Common when migrating to Substack, Ghost, or static-site generators.
• GPX (GPS Exchange Format), <trkpt> trackpoints with lat, lon, ele, time become rows. Useful for route analysis.
• KML (Google Earth), <Placemark> entries with names, descriptions, coordinates.
• iTunes / Apple plist XML in repeating-record form, playlist entries, app metadata.
• OFX / QFX / CAMT bank statement XML: transactions become rows for accounting imports.
• Product catalogue feeds: many e-commerce platforms ship XML feeds with <product> repeating elements for CSE submissions.

How Attributes, Nesting, and Repeated Children Are Handled

• Attributes like <book id="42"> are flattened into columns. The converter uses the attribute name directly as the column header (id) when it's unambiguous.
• Nested elements are flattened with dot notation: <person><address><street>Main</street><city>NYC</city></address></person> produces columns address.street and address.city. This is the same convention Pandas's json_normalize uses for nested JSON.
• Repeated child elements like <tags><tag>a</tag><tag>b</tag></tags> can be a problem: there's no obvious flat representation. Pre-process if you need column-per-tag or row-per-tag output.
• The five predefined entity references (&, <, >, ', ") are unescaped during conversion, so Tom & Jerry in XML becomes Tom & Jerry in the CSV cell.
• CDATA sections are unwrapped, the contents become the cell value as-is.
• Comments and processing instructions are dropped; CSV has no equivalent.

Encoding: The Excel Trap

XML declares its encoding via <?xml version="1.0" encoding="UTF-8"?>. CSV has no encoding declaration; the consumer guesses. Excel on Windows defaults to Windows-1252, so opening a UTF-8 CSV without a Byte Order Mark displays mojibake (é becomes é, ü becomes ü). The fix: either save the CSV with a UTF-8 BOM () at the start, use Excel's Data → From Text/CSV import wizard and explicitly select UTF-8, or open the file in Google Sheets, which handles UTF-8 correctly without a BOM.

Delimiter Choice

Per RFC 4180, the canonical CSV delimiter is comma. The tool also supports semicolon, tab, and pipe, pick the one that suits your audience:

• Comma: the default. Excel reads it when the OS regional setting is English. Safe for most use cases.
• Semicolon: preferred in continental Europe and Latin America, where the comma is the decimal separator. Excel uses the OS list separator, so a French- or German-locale Excel produces semicolon-delimited CSV.
• Tab: useful when fields contain commas (addresses, free text). Common in scientific data.
• Pipe: falls back to a delimiter that's rare in any natural data. Used in some legacy enterprise systems where the data may contain commas, semicolons, AND tabs.

Per RFC 4180, fields containing the chosen delimiter, line breaks, or double quotes are automatically wrapped in double quotes; embedded double quotes are escaped by doubling. The same quoting rules apply regardless of which delimiter you pick.

Privacy

XML payloads often contain confidential information: bank-statement transactions, internal employee data, scraped sitemaps revealing internal URLs, healthcare records, NDA'd product catalogues. The browser's built-in DOMParser runs entirely in your tab, there's no network request, no server roundtrip, no log entry. The data goes from your clipboard to a parsed in-memory tree, gets walked once for flattening, and the result lands in the output textarea. If you don't click Download, nothing is even written to disk.

Common Mistakes

1. Pasting XML that isn't a repeating-record shape. A document like a single config file with no repetition won't flatten to a usable CSV. The converter is designed for "list of similar items" XML.
2. Expecting attribute prefixes to round-trip. <product id="42"> becomes a column called id, not product@id or product.id. If you re-import the CSV elsewhere as XML, you'll need to remap.
3. Wrong delimiter for the audience. A comma-CSV opened in a French Excel installation can collapse to a single column. Match the delimiter to where the file will end up.
4. Forgetting the UTF-8 BOM for Excel. Non-Latin characters look broken in Windows Excel without the BOM. Either add it or open the file in Google Sheets / Excel for the web instead.
5. Trying to convert XHTML or DocBook. Mixed-content document XML doesn't flatten cleanly, use a proper XML/XSLT pipeline for those, not a tabular converter.
6. Pre-existing CSV-injection risk in field values. If your XML contains user-generated text and you're going to open the output in Excel or Sheets, cells starting with =, +, -, or @ are interpreted as formulas. OWASP documents this as a real attack class, sanitise before sharing exports of user-generated content.
7. Repeated child elements. If the XML has <tags> wrappers with multiple <tag> children, the flat output can't represent that cleanly. Either flatten to one row per tag (with parent fields repeated) or pre-process the XML to inline the tags as a delimited string.

More Frequently Asked Questions

Will the tool validate my XML against a schema?

No. It checks well-formedness only, using the browser's built-in DOMParser. If you need XSD or RELAX NG validation, use a dedicated tool like xmllint, Saxon, or the W3C XML Schema validator, well-formedness is sufficient for safe flattening into CSV.

How big can my XML be?

Whatever your browser can hold. There's no server-side limit because there's no server involved. Tens of megabytes convert in a second or two on a modern device. If you have hundreds of megabytes of XML, batch-split it before converting; running the whole thing through a single browser tab can run into memory limits.

Does the tool handle XML namespaces?

Yes, namespaced elements like <atom:link> are recognised and the prefix is preserved in the column name. If you don't want the prefix in your CSV headers, run a quick search-and-replace on the output to strip them.

Is my XML uploaded anywhere?

No. All parsing and flattening happens in your browser via the built-in DOMParser. The textarea contents are never transmitted, logged, or stored. Once the tab is closed, the data is gone.

What's the difference between this and the JSON-to-CSV tool?

Same goal (flatten hierarchical data into rows) but different input formats. XML is more verbose, allows attributes, has namespaces, and uses entity references for special characters. The XML-to-CSV converter handles those features specifically; the JSON-to-CSV converter expects array-of-object input. If you have JSON, use that tool instead; if you have XML, this one will give you a cleaner result.

Can I get the reverse conversion (CSV to XML)?

Not from this tool, but the reverse is generally easier, pick a row element name, wrap each row, and convert each column to a child element. A small Python or Node script with csv + xml.etree handles this in 20 lines. Or use a structured-data tool like Excel's Power Query, which can export CSV back to XML with a chosen schema.