Why an XML File Fails to Convert: The 8 Most Common XML Errors

Your file will not convert. The tool stops, or you get no output at all. This happens to almost everyone who works with XML, and most of the time the cause is small. One bad character in the wrong place can stop a whole file.

This guide lists the 8 most common xml file errors. For each one, you will see a tiny broken example and its fixed version, and learn how to find the spot and fix it.

XML is a text format for data. It uses tags to name each piece of data. A tag is a word in angle brackets, like <name>. When a file follows the basic rules of the format, we say it is well-formed.

What Well-Formed Means, in Plain Words

Well-formed means the file follows the core rules of XML. Every opening tag has a matching closing tag. Tags nest in the right order, like boxes inside boxes. There is one root element holding everything. The root element is the single outer tag that wraps the whole file content. Special characters in text are written in a safe way.

Well-formed is not the same as correct data. A file can be well-formed and still have a wrong price or a missing name. Those are data problems. A file that is not well-formed has a shape problem. The parser cannot even read it through. A parser is the part of a tool that reads a format and makes sense of it. Fix the shape first. Then you can check the data.

How an Error Message Helps You

A clear error message gives you a line number and a column number. The line number tells you which line of the file has the problem. The column number tells you how far across that line the problem sits. A column is one character position across the line.

Some rival tools fail silently with no message when they meet broken XML. You get nothing, and you have no clue where to start. XmlToCsv gives a clear error with line and column numbers for broken XML. That one detail can save you a long hunt.

Here is how to use a line and column report:

1. Open the XML file in a text editor. A text editor is a simple program for editing plain text. Do not use a word processor, which can add hidden formatting.
2. Turn on line numbers, and go to the line in the message. Many editors have a Go to Line command.
3. On that line, count across to the column. Count each character, starting at 1. Spaces count too.
4. Look at that spot, and a little before it. The true cause is often just before the spot named. A tag that was never closed may only be spotted when the next tag starts.

Fix one error at a time, save, and run the conversion again. Most files need only one or two fixes. You can also convert a valid file with the home page tool to test your fix right away.

The 8 Errors at a Glance

This table sums up all eight errors.

Error 1: Unclosed Tag

Every opening tag needs a closing tag. If you open <name> you must later close it with </name>. If the closing tag is missing, everything after it gets pulled inside, and the shape breaks.

Broken:

<product>
  <name>Blue Mug
  <price>12.50</price>
</product>

The <name> tag is never closed. The parser reads the price as part of the name, then meets a closing tag for product while name is still open.

Fixed:

<product>
  <name>Blue Mug</name>
  <price>12.50</price>
</product>

Add </name> right after the text. A special case is an empty element, an element with no content. You can close it in one tag with a slash at the end, like <image src="mug.png" />. That form is complete on its own.

Error 2: Mismatched Closing Tag

A closing tag must match its opening tag exactly, letter for letter. XML is case-sensitive. Case-sensitive means upper-case and lower-case letters count as different. <Name> and <name> are two different names in XML.

Broken:

<product>
  <Name>Blue Mug</name>
  <price>12.50</Price>
</product>

Name is closed with name, and price is closed with Price. Both differ in case, and both will fail.

Fixed:

<product>
  <name>Blue Mug</name>
  <price>12.50</price>
</product>

Make each closing name match its opening name, case and all. This error also happens with a plain typo, like closing <price> with </prce>. Compare the two names side by side, one letter at a time. Tags must also nest in order: close a child tag first, then its parent.

Error 3: A Raw & or < in Text

Some characters have a special job in XML. The & character starts an escape code. An escape code is a short written form that stands for a special character. The < character starts a tag. Because they have those jobs, you cannot use them as plain text in your data.

Broken:

<product>
  <name>Fish & Chips Set</name>
  <note>Serves 2 < 4 people</note>
</product>

The raw & and the raw < will both break the file. The parser sees & and expects an escape code to follow. It sees < and expects a tag name to follow. What follows does not fit, so it reports an error.

Fixed:

<product>
  <name>Fish &amp; Chips Set</name>
  <note>Serves 2 &lt; 4 people</note>
</product>

Write & when you mean & in text, and < when you mean <. When the file is converted, those codes turn back into the real characters in your CSV. This error is common in names and titles. Company names with an & are a classic source.

Error 4: More Than One Root Element

An XML file must have exactly one root element. All other elements sit inside that one root. Two roots side by side is not allowed.

Broken:

<product>
  <name>Blue Mug</name>
</product>
<product>
  <name>Red Plate</name>
</product>

It looks tidy, but there is no single root. The file is two fragments, not one document. A fragment is a piece of XML that is not a full document on its own.

Fixed:

<products>
  <product>
    <name>Blue Mug</name>
  </product>
  <product>
    <name>Red Plate</name>
  </product>
</products>

Wrap everything in one root, here <products>. This fault often appears when someone joins two files by hand. The wrapper also holds the records, and each repeating record tag inside it becomes a row.

Error 5: Duplicate Attribute on One Element

An attribute is a name and value placed inside an opening tag. An element can have many attributes, but each attribute name can appear only once on that one element.

Broken:

<product id="p101" id="p102">
  <name>Blue Mug</name>
</product>

The id attribute appears twice on the same tag. The parser cannot know which value is the real one, so it stops.

Fixed:

<product id="p101">
  <name>Blue Mug</name>
</product>

Keep one value and remove the other. Before you delete, think about which value is right. If two systems gave the same item two ids, note that clash for whoever owns the data. Attributes matter in conversion too: XmlToCsv keeps attributes as columns, named like product@id.

Error 6: Invalid Characters

Not every character is allowed in XML. Control characters are hidden codes that once told old machines what to do. They have no place in normal text, and most of them are banned in XML. You cannot see them, which makes this error feel unfair.

These characters often arrive by paste. You copy text from Word or from a PDF, and hidden codes come with it. The text looks clean, but the file carries codes the parser rejects.

Broken, shown with a mark where the hidden character sits:

<product>
  <name>Blue [hidden] Mug</name>
  <price>12.50</price>
</product>

In a real file, you may see nothing odd at that spot, or a small box. The error line and column are your best guide.

Fixed:

<product>
  <name>Blue Mug</name>
  <price>12.50</price>
</product>

Go to the line and column in the message. Retype the text around that spot by hand, or delete the hidden character. Pasting as plain text first helps strip these codes out.

Error 7: Encoding Mismatch

Encoding is the way text characters are stored as bytes in a file. The first line of an XML file, called the declaration, often names the encoding, like this: <?xml version="1.0" encoding="UTF-8"?>. UTF-8 is the most common encoding on the web today.

The error happens when the declaration says one encoding, but the file was saved in another. The parser trusts the declaration and reads the bytes by those rules. Letters with accents then come out wrong. The result is garbled text, sometimes called mojibake. Mojibake means text that shows as strange symbols because it was read with the wrong encoding. In worse cases, the parser stops.

Broken:

<?xml version="1.0" encoding="UTF-8"?>
<product>
  <name>Café Cup</name>
</product>

In this case the first line says UTF-8, but the file was saved as another encoding, so the name does not read as Café Cup.

Fixed: save the file again in an editor, and choose UTF-8, so the file matches its declaration. Or change the declaration to name the true encoding. The declaration and the saved bytes must agree.

XmlToCsv reads the file encoding from its BOM or declaration. A BOM is a small mark at the very start of a file that names its encoding. Supported encodings include UTF-8, UTF-16, ISO-8859-1, and windows-125x. The trouble is only when the label and the bytes disagree.

Error 8: Junk Before the Declaration or After the Root

An XML file must start clean and end clean. The declaration, if there is one, must be the very first thing in the file. Nothing can come before it. And after the root element closes, nothing but white space should follow.

Broken:

Here is the new file:
<?xml version="1.0" encoding="UTF-8"?>
<products>
  <product>
    <name>Blue Mug</name>
  </product>
</products>
-- end of export --

The note at the top and the line at the bottom are both junk in XML terms. Junk here means any text that sits outside the allowed places. The top note breaks the rule that the declaration comes first. The bottom line is text after the root has closed.

Fixed:

<?xml version="1.0" encoding="UTF-8"?>
<products>
  <product>
    <name>Blue Mug</name>
  </product>
</products>

Remove all text before the declaration and after the closing root tag. Keep notes in a separate text file. This error often comes from email or chat, where someone adds a line above or below a pasted file.

A Valid Example, With Its CSV Result

Here is a small valid file with two records. The repeating tag is <product>, so each product becomes one row.

<?xml version="1.0" encoding="UTF-8"?>
<products>
  <product id="p101">
    <name>Blue Mug</name>
    <price>12.50</price>
  </product>
  <product id="p102">
    <name>Red Plate</name>
    <price>9.00</price>
  </product>
</products>

Here is the CSV result:

product@id,name,price
p101,Blue Mug,12.50
p102,Red Plate,9.00

The id attribute became the product@id column. Each field became a column, and each product became a row. XmlToCsv shows a preview of the first rows plus the total row count, so you can check the result before you download. Exports are CSV and XLSX.

After your file parses, the next choices are about shape, not errors. You can follow the full XML to CSV steps once your file is fixed, and then work on picking the row element after the file parses if the rows do not look right.

A file can also parse cleanly and still lose data in conversion if fields are handled badly. That is why silent data loss is the other failure mode to watch for once your file converts at all.

A Calm Fixing Routine

When a file fails: read the message and note the line and column; go to that spot in a text editor; check the eight errors against that spot; fix just that one fault and save; then run the conversion again. When the file parses, check the preview rows and the total row count before you download.

Keep a copy of the broken source before you start. Fix a working copy, so you can go back if a fix makes things worse. If the same error comes from the same export each week, ask for a fix at the source.

The Key Idea to Keep

Almost every XML failure comes from a small, plain cause: a tag left open, a name that does not match, a raw &, a second root, a repeated attribute, a hidden character, a wrong encoding label, or junk at the edges of the file. None of these need deep skill to fix. They need a clear message that names the line and column, a text editor, and a calm pass, one error at a time.

References

• https://www.w3.org/TR/xml/ — The W3C XML specification, which defines well-formedness and the core rules of XML.
• https://developer.mozilla.org/en-US/docs/Web/XML/Introduction — MDN's introduction to XML, a clear overview of the format and its basic rules.