To convert XML to CSV, the XML to CSV Converter flattens a predictable set of repeating record elements into a rectangular comma-separated table directly in your browser, without uploading the document. You paste well-formed XML, type the exact qualified name of the repeating element (such as item or ns:item), and the tool walks each match with the browser's DOMParser, turning one record per row. Attributes on the record become columns prefixed with @, direct child elements become columns using their exact tag names, and any child that appears more than once in a record is collapsed into a compact JSON array inside a single CSV cell. Output follows the RFC 4180 profile (commas, CRLF line endings, and doubled quotes for embedded quotes), and a default formula-protection option prefixes values starting with =, +, -, or @ with a tab inside quoted fields to prevent accidental spreadsheet formula execution, following the OWASP mitigation guidance. Because the parse and serialize happen locally, the XML document never leaves the page.
When you need to convert XML to CSV
XML stores records as a tree; CSV stores them as rows. That shape mismatch is the reason most people search for a way to convert XML to CSV in the first place. Enterprise catalogs, product feeds, accounting exports, configuration dumps, and SOAP-style responses arrive as nested markup, but the spreadsheet, the data warehouse, or the downstream script wants a flat file with one header row and one record per line. Trying to force the XML open in Excel or Numbers usually produces a single column with the raw tags still embedded, which is not useful for analysis.
The XML to CSV Converter solves that gap for the common case where the document contains a repeating element acting as the row boundary. Think of a catalog file with many <item> elements, a price list with many <product> elements, or a feed with many <entry> elements. Once you tell the tool which tag is the record, it can produce a rectangular table. Because parsing and serialization happen in the browser, the document is never uploaded, which matters for internal exports and client data that should not leave the machine.
How the converter maps XML to CSV columns
The mapping is intentionally predictable. Every record element matched by the qualified name you enter becomes one row. Within that record, the tool walks attributes and direct child elements and emits a deterministic union of columns based on what it sees across the document.
| XML construct inside a record | CSV column treatment |
|---|---|
| Attribute on the record element (id="42") | Column named @id with the attribute value as text |
| Single direct child element (<price>9.99</price>) | Column named price with the trimmed text content |
| Same direct child repeated (<tag>a</tag><tag>b</tag>) | One column named tag whose value is ["a","b"] in compact JSON |
| Nested markup under a child | Flattened to descendant text; structure and child attributes are not preserved |
| Direct text outside any child element | Becomes a #text column only when not pure whitespace |
| Missing column on a later record | Empty field; column order follows the first-seen union |
| DOCTYPE declaration at the top | Rejected before parsing; the converter does not process DTD defaults or external entities |
| Malformed tag, quote, or entity | Parser returns an error document and the conversion is blocked |
Column order is deterministic: fields from the first record appear first, and any previously unseen fields from later records are appended. The first row of the CSV is the header row built from that union, which is why the column count you see in the spreadsheet should match the union of tags and attributes across all records, not just the first one.
Convert XML to CSV in three steps
The full workflow takes about a minute once your XML is clean.
- Open the XML to CSV Converter in your browser. Paste the full XML document into the input area. The parser treats the input as application/xml, so make sure the document is well-formed: matching tags, balanced quotes, and valid entities. Malformed input is reported and conversion is blocked, not silently truncated.
- Enter the exact qualified name of the repeating record element. For a flat catalog use the bare tag such as item. For a namespaced feed use the prefix as it appears in the markup, such as ns:item. The match is case-sensitive and uses getElementsByTagName under the hood, so a typo or wrong case returns zero rows and a no-match error.
- Leave formula protection on for any CSV that will be opened by a human in Excel, Google Sheets, or Numbers. Click convert, then verify the record and column counts against your source XML before downloading or copying. The downloaded file is plain UTF-8 text/csv with no byte-order mark.
If your document has more than one plausible row element, run the conversion once for each candidate tag and compare the record counts. Whichever count matches the expected number of records in the source is your row boundary.
Output format, encoding, and formula protection
The CSV output follows the RFC 4180 profile documented at RFC 4180. Columns are comma-separated, records use CRLF line endings, fields containing commas, double quotes, tabs, carriage returns, or line feeds are wrapped in double quotes, and any embedded double quote is doubled. Spaces inside fields are preserved. Missing columns become empty fields rather than skipped cells, which keeps the column count stable across rows.
Two safety details matter when the destination is a spreadsheet. First, spreadsheet programs may interpret cells that begin with =, +, -, or @ as formulas and execute them when the file is opened, which is the CSV injection pattern tracked by OWASP. The protection option is enabled by default and prefixes those values with a tab character inside the quoted field, an Excel-oriented mitigation. This intentionally changes the cell data, so disable the option only when the downstream consumer treats every cell as inert text or when you need byte-exact raw values. Second, the downloaded file is UTF-8 text/csv without a byte-order mark. Most modern spreadsheets open it correctly, but some legacy configurations require an import wizard or an explicit UTF-8 selection. Dates, numbers, leading zeros, identifiers, and Booleans remain text spellings from the XML; a spreadsheet may still guess types when opening the file, so import with controlled column types when leading zeros or numeric precision must survive.
Hard limits, errors, and how to verify the result
The converter fails rather than truncating, which keeps downstream consumers safe but means you should size your inputs up front.
| Limit | Value |
|---|---|
| XML input size | 500,000 characters |
| Matching records | 10,000 |
| Columns in the output | 200 |
| CSV output size | 5,000,000 characters |
When conversion fails, the cause is usually one of three things. A parser error means the XML is not well-formed: fix the tag, quote, or entity, then retry. A no-match error means the qualified record name is wrong or cased differently: open the document and copy the exact tag string, including any namespace prefix. A DOCTYPE rejection means the document declares a DTD; remove the DOCTYPE line, since the converter deliberately does not process external entities, DTD defaults, or custom entity definitions. After a successful run, compare the row and column counts in the spreadsheet against the source XML before treating the file as a production export.
When this converter is not the right fit
XML has no universal record-to-table mapping, and the converter makes no attempt to invent one. It is built for predictable feeds such as a catalog of repeated item elements with scalar child text. It does not infer records automatically, expand nested arrays into multiple rows, join parent values into children, evaluate XPath, normalize namespaces, preserve XSD types, validate against a schema, or convert arbitrary mixed-content documents without loss. When the same data needs to survive any of those transformations, an explicit pipeline such as XSLT, a streaming parser in code, or a dedicated ETL tool is the correct contract. Use this tool when the document already follows a flat, predictable shape and the goal is a quick, private, copy-ready table.