XML to CSV Converter

By finding the repeating element. Almost every XML document that maps sensibly onto a table has one element that appears many times under a common parent — item under items, book under catalog, entry under feed. That repeating element becomes the row and its children become the columns. The tool picks the most frequent repeating element automatically, and lets you override it, because a document with several repeating groups is genuinely ambiguous and only you know which one you meant.

They are flattened into dotted column names, so an author element containing a name becomes a column called author.name. That is the only way arbitrary nesting fits into a flat table, and it keeps the path visible so you can reconstruct the structure if you need to. Nesting more than two or three levels deep produces very long column names, which is usually a sign that the data is not naturally tabular and a different target format would serve you better.

Yes, and this is where XML differs most from JSON. An attribute like id on a book element becomes its own column, because attributes carry real data in most XML formats — often the identifier you most want. Without them the export would be missing exactly the field you need to join on. They are distinguished from child elements in the column naming so you can tell which was which if you ever need to write the XML back.

Because XML does not require every record to carry every element. If half your items have a discount element and half do not, the discount column exists and is empty for the rest — which is correct, and matches how the data actually is. A large number of empty cells usually means the repeating element was chosen at the wrong level, or that the document genuinely contains several different record types under one parent, in which case one table cannot represent it faithfully.

Prefixed element names are kept as written, so a soap:Body element produces a column with the prefix intact. They are not resolved to their declared URIs, which for a flattening job is the pragmatic choice — the prefix is what you will recognise, and resolving it would produce column names nobody wants to read. For documents where prefix resolution genuinely matters to the meaning, this is a readable export rather than an authoritative transformation.

Yes. When a row contains its own repeating child — several tag elements inside each item, say — those are joined into a single cell rather than becoming columns, because the count varies per row and a table needs a fixed shape. The alternative is one column per index, which produces a very wide and mostly empty table. Joining is the more useful default; if you need the values separately, converting to JSON first and working from there preserves the structure properly.