I build toolz.dev, and a recurring job across the WordPress and Laravel work I do is feeding data into systems that were designed a decade or two ago. Plenty of them still speak XML and only XML: a product feed for a marketplace, an import format for an accounting package, a SOAP endpoint that will not look at anything else. The data almost always arrives as a CSV export from a spreadsheet, so the task is to turn flat comma-separated rows into a structured XML document. I have watched that go wrong in every possible way, from a customer name containing a comma that split into two columns, to an ampersand in a company name that made the whole file fail to parse. The CSV to XML converter exists to do that conversion correctly, in the browser, without pasting a customer list into some anonymous server. This guide covers what the conversion involves, why the tricky parts are tricky, and how to shape the output for whatever is going to read it.
TL;DR: A CSV to XML converter reads comma-separated rows and writes them as a well-formed XML document, with each row becoming an element and each cell becoming either a named child element or an attribute. It parses CSV per RFC 4180, so quoted fields containing commas, quotes, or line breaks survive intact; it auto-detects whether the delimiter is a comma, semicolon, tab, or pipe; it coerces column names into valid XML tags; and it escapes the markup-significant characters so the output always parses. It runs entirely in your browser, so the data in your CSV is never uploaded.
What is the difference between CSV and XML?
CSV, comma-separated values, is a flat text format. Each line is a record, and within a line each field is separated by a delimiter, usually a comma. It is compact, every spreadsheet can export it, and it is trivial for a human to read. What it cannot do is express structure or meaning. There is nothing in a CSV that says what a column means, no nesting, no types; a cell holding true and a cell holding the word true are indistinguishable, and a value that itself contains a comma needs special quoting to avoid being read as two fields.
XML, the Extensible Markup Language, is the opposite trade. Every value is wrapped in a named tag, so <name>Ada Lovelace</name> carries both the value and the label for it. That verbosity buys structure: elements nest, documents can be validated against a schema, and a stylesheet can transform the whole thing. The rules for what counts as well-formed XML are set out in the W3C XML 1.0 specification, and they are strict in ways CSV never is, which is exactly why a mechanical conversion has to be careful. Converting CSV to XML is fundamentally about adding the structure and the escaping that CSV leaves implicit.
How does a row become an element?
The natural mapping treats the first CSV row as the header, holding the column names, and every following row as one record. Each record becomes a row element, and inside it each cell becomes a child element named after its column. So a CSV of id,name,role with a data row 1,Ada Lovelace,Engineer becomes:
<rows>
<row>
<id>1</id>
<name>Ada Lovelace</name>
<role>Engineer</role>
</row>
</rows>
The outer rows element is the document root, because a well-formed XML document must have exactly one top-level element wrapping everything else. The converter lets you rename both the root and the per-row element, so you can produce <catalog><product>...</product></catalog> instead when that is what your target expects. The column names become the tag names, which is where the first real constraint bites, because not every column heading is a legal XML tag.
Why do some column names get changed?
XML element names are not free-form. The specification says a name must start with a letter or underscore and may then contain letters, digits, hyphens, periods, and underscores, but not spaces and not most punctuation, and it may not start with a digit. A spreadsheet column called First Name or Unit Price ($) or 2024 Total is a perfectly good heading and an illegal XML tag. If a converter emitted <First Name> the document would not parse at all.
So the tool sanitizes every column name into a valid tag. Spaces and illegal characters become underscores, so First Name becomes First_Name, and a name that starts with a digit gets an underscore prefix so 2024 Total becomes _2024_Total. If two columns sanitize to the same tag, or the header genuinely repeats a name, the duplicates get a numeric suffix so no column silently overwrites another, and the tool warns you when it has done this. The important guarantee is that only the tag names are adjusted; the data inside every cell is passed through untouched. If you need the original labels preserved exactly, attribute mode, covered below, is often a better fit because attribute names face the same rules but you can also choose to carry the heading as a value elsewhere.
What about commas and quotes inside a value?
This is the part that breaks naive converters, and it is worth understanding. CSV has a quoting convention, formalized in RFC 4180, for values that contain the delimiter or a line break. Such a value is wrapped in double quotes, and any literal double quote inside it is written as two double quotes. So a company field holding Hopper, Grace is stored in the CSV as "Hopper, Grace", and a note reading she said "hi" is stored as "she said ""hi""".
A converter that splits each line on commas will mangle both of these, turning one field into two and leaving stray quotes everywhere. This tool uses a proper state-machine parser that tracks whether it is inside a quoted field, so an embedded comma, an embedded quote, and even a newline inside a quoted value are all read as part of the single field they belong to. That is the difference between a customer named Smith, John arriving as one <name> element and arriving as a broken record with an extra column. If your export came out of Excel, Google Sheets, or a database dump, it almost certainly uses this quoting, and parsing it correctly is not optional.
Once the value is safely parsed, it still has to be made safe for XML, which is a separate escaping problem. Five characters are special in XML, and the three that matter in element text are the ampersand, the less-than sign, and the greater-than sign. A cell containing Ben & Jerry's or x < y would produce invalid XML if written literally, so the converter replaces them with the predefined entities &, <, and >. In attribute values the double quote is escaped as well. This escaping is what guarantees the output parses no matter what the data contains.
Should each cell be an element or an attribute?
XML gives you two places to put a value: as the text of a child element, or as an attribute on the row element. The converter supports both, and which one is right depends entirely on the system that will read the file. Element mode produces the readable, nestable form:
<row>
<name>Ada</name>
</row>
Attribute mode collapses the whole row into a single self-closing element:
<row name="Ada" role="Engineer"/>
Here is how the two compare on the dimensions that usually decide it:
| Consideration | Child elements | Attributes |
|---|---|---|
| Readability | Higher, one value per line | Denser, one row per line |
| File size | Larger, tags repeated | Smaller |
| Can nest further later | Yes | No |
| Repeated values per column | Allowed | One value per attribute name |
| Typical fit | Document-style data, feeds | Compact records, config |
As a rule of thumb, if the data is record-like and flat and the reader wants it small, attributes are fine; if the data might grow structure later, or a human will read it, elements are the safer default. When you are unsure what the consuming system wants, elements are the more conservative choice because anything that accepts attributes can also be adapted to elements, but the reverse is not always true.
How to use the CSV to XML converter
Step 1: Paste your CSV
Paste or type your CSV into the input box. A block copied straight from Excel or Google Sheets works, as does the contents of a .csv file, including quoted fields that contain commas or line breaks.
Step 2: Set the options
Leave the delimiter on auto-detect or choose one explicitly, confirm whether the first row is a header, set the root and row element names, and pick whether each cell becomes a child element or an attribute. You can also toggle the XML declaration and switch between indented and minified output.
Step 3: Convert
Click Convert to XML. The tool parses every row, sanitizes the column names into valid tags, escapes the markup characters, and assembles a well-formed document, warning you about any renamed columns or ragged rows.
Step 4: Copy or download
Copy the XML to your clipboard or download it as a .xml file. If the shape is not quite right for the target system, adjust the element names or switch between element and attribute mode and convert again.
Why auto-detect the delimiter?
Not every "CSV" is separated by commas. Exports from European locales frequently use a semicolon, because the comma is the decimal separator in those regions, and data pulled from a database or a log is often tab-separated. A converter locked to commas would read a semicolon file as a single wide column and produce nonsense. This tool detects the delimiter by trying comma, semicolon, tab, and pipe and picking whichever produces a consistent column count across the first several rows, which is a far more reliable signal than raw frequency because a comma inside prose appears often but irregularly. You can always override the guess when a file is unusual, but for the common cases the detection means you paste and go.
Ragged rows, where a line has more or fewer fields than the header, are the other real-world mess. The converter pads short rows with empty elements and warns you rather than silently dropping data, so you can see that row 47 was missing its last two fields instead of discovering it downstream. Extra fields beyond the header get generic column names so nothing is lost, and the warning tells you exactly how many rows were affected, which is usually enough to trace the problem back to a stray delimiter in the source. If you want to inspect a messy file before converting it, the CSV viewer renders it as a table with the same tolerant parser, which is often the fastest way to spot a stray delimiter or an unclosed quote before it becomes malformed output.
Where the CSV to XML converter fits with everything else
Data conversion is rarely a single hop. The same CSV that needs to become XML today might need to become JSON tomorrow for a REST API, or a batch of SQL inserts for a database load. The CSV to JSON converter handles the JSON target with the same RFC 4180 parser, and the CSV to SQL converter turns the same rows into insert statements. When the data is already XML and you need to go the other way, the XML to JSON converter and the JSON to XML converter cover both directions of the XML-JSON boundary, and they use the same attribute-and-text conventions this tool follows, so the round trip is predictable.
For the wider picture, the CSV to JSON guide digs deeper into parsing the same messy exports, the JSON to XML guide explains the element-and-attribute mapping from the JSON side, and the data privacy in online tools article explains why doing all of this in the browser matters when the CSV holds names and email addresses. Like everything on toolz.dev, the converter runs entirely in your browser, so the data you convert never leaves your machine.
Frequently asked questions
How do I convert a CSV file to XML?
Paste the CSV into the input box, confirm the delimiter and header settings, and click Convert to XML. The first row is read as the column names, and every following row becomes an XML element whose child tags are named after those columns. You can then copy the result or download it as a .xml file.
What happens to the CSV header row?
When "first row is header" is on, the header cells become the XML element names for every data row. Names are sanitized into valid XML tags, so "First Name" becomes First_Name and a duplicate column is renamed with a numeric suffix. If you turn the header option off, columns are named column_1, column_2, and so on.
Should each cell be an element or an attribute?
It depends on the system reading the XML. Element mode writes a readable nestable structure with one tag per value, while attribute mode collapses a row into a single compact element with one attribute per column. This converter supports both, so pick the one your schema or import target expects; elements are the safer default when you are unsure.
Does the converter handle commas inside a value?
Yes. Following RFC 4180, a value that contains a comma, a double quote, or a line break is wrapped in double quotes in the CSV, and an embedded quote is written as two quotes. The parser reads those quoted fields as a single value rather than splitting them, so "Hopper, Grace" stays in one element.
What delimiters are supported?
Comma, semicolon, tab, and pipe. By default the tool auto-detects the delimiter by choosing the one that produces a consistent number of columns across the first several rows, which correctly handles European semicolon files and tab-separated exports. You can also select the delimiter manually.
Why are some of my column names changed in the XML?
XML element names cannot contain spaces or most punctuation and cannot start with a digit or hyphen. The converter replaces illegal characters with underscores and prefixes a name that starts with a digit, so the output is always well-formed. The original data in each cell is never changed, only the tag names.
Is my CSV data uploaded to a server?
No. The entire conversion runs in your browser with JavaScript. Nothing you paste is transmitted, logged, or stored, and the tool keeps working with no network connection once the page has loaded, which keeps names, emails, and other data in your CSV private.
Can I convert XML back to CSV or to JSON?
This tool converts CSV to XML. To reshape the data the other way, use the XML to JSON converter, and use the CSV to JSON converter when JSON rather than XML is your target. All of them run client-side with the same privacy guarantees.
