How to Validate XML and Fix Common Parse Errors

The short answer

Paste your XML into the XML Formatter & Validator. If it is well-formed, you see an indented version straight away; if not, you see a red error from your browser's XML parser instead. Most errors come from five mistakes: a tag that is never closed, opening and closing tags that do not match, a bare & character, an attribute value without quotes, or more than one root element.

Well-formed vs valid: what this check covers

There are two levels of "correct" XML:

• Well-formed means the syntax follows the XML rules: every tag is closed, tags nest properly, attribute values are quoted, special characters are escaped and there is exactly one root element. Any XML parser will refuse a document that is not well-formed.
• Valid means the document is well-formed *and* matches a schema (an XSD or DTD) that says which elements and attributes are allowed.

The XML Formatter checks well-formedness using the XML parser built into your browser. It does not load or check against an XSD schema. If an API or system says your XML "does not validate against the schema", the problem is the content (a missing element, a wrong data type), not the syntax, and you need the schema to find it.

How to check your XML

Open the XML Formatter & Validator. It opens with a small sample book catalogue; click Load sample any time to bring it back.

Select the sample text and paste your own XML over it.

Look at the right-hand panel. It updates as you type. Formatted XML with 2-space indentation means the document parsed successfully; a red message starting with ⚠ means the parser found an error.

Fix the line the message points to and watch the panel. When the error disappears, the document is well-formed.

Click Copy to copy the formatted result.

The wording of the error message comes from your browser, so Chrome, Firefox and Safari describe the same problem slightly differently. Most include a line and column number. Count from the first line of what you pasted.

The five most common XML errors and how to fix them

1. A tag is never closed

Every opening tag needs a matching closing tag, or must close itself.

• Broken: <price>45.99
• Fixed: <price>45.99</price>
• Also fine for empty elements: <discount/>

HTML lets you leave some tags open, such as <br> or <li>. XML never does, so HTML snippets pasted into XML are a frequent cause of this error.

2. Tags do not match or overlap

XML is case-sensitive and tags must close in reverse order.

• Broken: <Title>Clean Code</title> (capital T vs small t)
• Broken: <b><i>text</b></i> (closed in the wrong order)
• Fixed: <b><i>text</i></b>

3. A bare ampersand or less-than sign in text

The characters & and < have special meaning in XML. Inside text or attribute values you must write them as entities.

Character	Write it as
&	&
<	&lt;
>	&gt; (recommended)
double quote inside an attribute	&quot;
single quote inside an attribute	&apos;

Company names (Johnson & Johnson), URLs with query strings (?a=1&b=2) and maths in product descriptions are the usual culprits. If a block of text has many special characters, you can wrap it in a CDATA section instead: <![CDATA[ 5 < 6 & 7 > 3 ]]>.

4. An attribute value without quotes

• Broken: <book id=1>
• Fixed: <book id="1"> or <book id='1'>

The same element also cannot have the same attribute twice.

5. More than one root element

An XML document must have exactly one top-level element that contains everything else.

• Broken: two <book> elements side by side with nothing around them.
• Fixed: wrap them in one parent, such as <catalog> ... </catalog>.

This often happens when you copy a few records out of a larger file to test them.

Other errors you may meet

• Text before the XML declaration. The <?xml version="1.0"?> line, if present, must be the very first thing in the document. Even a blank line or space before it causes an error.
• Element names starting with a digit or containing spaces. <2024-sales> and <first name> are not allowed. Use <sales-2024> and <first_name>.
• Undefined entities. XML only knows five built-in named entities (amp, lt, gt, quot, apos). HTML entities such as   cause an error unless a DTD defines them. Use the numeric form   instead.

Getting the best formatted output

The formatter puts each tag on its own line and indents child elements by two spaces. Keep these points in mind:

• It works best on compact XML, such as a one-line API response. If your input already has line breaks and indentation, that whitespace is kept, so the output looks much the same as the input.
• The output is produced by your browser's XML serializer, so small details can change. Check the first line: depending on the browser, the <?xml ...?> declaration may not appear in the formatted version. Add it back if the receiving system needs it.

About the JSON view

Click JSON in the output panel to see a quick JSON version of the same data. It is handy for reading a structure, but it is a simplified conversion:

• Attributes are dropped. In the sample, id="1" does not appear in the JSON.
• The root element's name is not included; you see its children.
• Repeated elements with the same name, such as several book entries, become an array.
• Every value is a string. 45.99 becomes "45.99".

For data you will feed into code, use a conversion that keeps attributes, and then check the result with the JSON Formatter. For background on JSON syntax, see how to format JSON online.

Comparing two versions of an XML file

If a file used to work and now fails, paste both versions into the Code Diff Checker to see which lines changed, then check those lines first.