How to Validate XML and Fix Not-Well-Formed Errors

You paste XML into a parser and it throws a wall of red: "not well-formed," "junk after document element," or a line and column number that means nothing at a glance. Almost every one of these errors comes from one of seven syntax mistakes, and each has a quick, predictable fix. The free browser-based Static.app XML viewer flags input that is not well-formed and re-indents the rest, which is how you find the break.

Well-formed vs. valid: two different checks

Well-formedness is a syntax check, and validity is a schema check on top of it. A well-formed document obeys the XML syntax rules. A valid document is well-formed and also conforms to a DTD or XSD. People use the two words interchangeably, but knowing which check is failing tells you where to look.

• Well-formed is about syntax only. The document has exactly one root element, every tag is closed, tags nest correctly, attribute values are quoted, and the special characters &, <, and > are escaped. Tag names are case-sensitive, so <Title> and </title> do not match. If any of these rules break, no XML parser will read the file at all.
• Valid is a stricter, optional check on top of well-formedness. A valid document is well-formed and conforms to a schema, either a DTD or an XSD, that defines which elements are allowed, in what order, and with which attributes. A document can be perfectly well-formed but still invalid against a schema.

Most day-to-day "my XML won't parse" problems are well-formedness problems. Fix the syntax first, and worry about schema conformance after the parser can actually load the file.

The common not-well-formed errors and how to fix each

Seven syntax mistakes account for nearly every not-well-formed error: unclosed or mismatched tags, more than one root element, unescaped ampersands and angle brackets, unquoted attribute values, stray characters before the prolog, wrong nesting order, and invalid control characters. Each one has a single mechanical repair.

Unclosed or mismatched tags

Every opening tag needs a matching closing tag with the same name and case. <item>shoes</item> is fine; <item>shoes or <item>shoes</Item> is not. Empty elements can self-close as <br/>. When a parser reports an unexpected end of file, a tag left open earlier is usually the cause.

More than one root element

An XML document must have a single top-level element that wraps everything else. Two top-level siblings with nothing around them, like <user>...</user><user>...</user>, trigger "junk after document element." Wrap them in one container such as <users>...</users>.

Unescaped ampersands and angle brackets

A raw & starts an entity reference, so Ben & Jerry inside text content is an error. Write Ben & Jerry. Likewise a literal < or > in text must be written as < or >. If your content has a lot of markup-like text, wrap it in a <![CDATA[ ... ]]> section instead of escaping every character.

Unquoted attribute values

Every attribute value needs quotes. <book id=42> is invalid; use <book id="42">. Single or double quotes both work, as long as they match on the same attribute.

Stray characters before the prolog

The XML declaration <?xml version="1.0"?> must be the very first thing in the file, with no spaces, blank lines, or characters before it. A common hidden culprit is a UTF-8 byte-order mark (BOM) or whitespace copied in ahead of the declaration, which produces errors like "content is not allowed in prolog." Delete anything sitting before the <?xml.

Wrong nesting order

Tags must close in the reverse order they opened. <b><i>text</b></i> is out of order; the correct form is <b><i>text</i></b>. Overlapping elements are one of the most common structural mistakes when XML is hand-edited.

Invalid characters

XML 1.0 does not allow most control characters, such as a raw form feed or a null byte, even if they look invisible. These often sneak in from copy-and-paste out of another program. Removing the offending byte, or replacing it with a valid character reference, clears the error.

How the XML viewer surfaces the break

The Static.app XML viewer surfaces the break by re-indenting the document and refusing to format input that is not well-formed. Reading a raw parser error is a lot easier when you can see the document formatted. The free XML viewer is built for exactly this job, and it runs entirely in your browser: nothing you paste is uploaded to a server.

1. Paste your XML into the input panel, or open an .xml file from your computer. There is a Sample button if you want to try it first.
2. Click Format. The XML viewer re-indents the document with proper nesting so the structure is easy to scan, and it checks that the input is well-formed as it goes.
3. If something is broken, the viewer flags the problem instead of quietly formatting garbage, so you can jump to the unclosed tag or stray character and fix it.
4. Once the document is clean, copy the formatted result or download it as a file.

On the security side, the XML viewer refuses DOCTYPE declarations and external entities, which means it is safe against XXE (XML external entity) attacks. You should never "enable external DTD loading" to make a stubborn document parse; that is the exact door XXE walks through. If a file only parses with external entities turned on, treat that as a red flag in the file, not a setting to change.

After it is well-formed

Once your XML is well-formed, the Static.app XML to JSON converter turns the document into a structured JSON object. That is the shape a JavaScript app or API usually expects. And if you are weighing which format to reach for in the first place, the JSON vs. XML guide breaks down where each one fits.

Common questions

The four answers below cover what separates well-formed from valid, why a bare ampersand breaks a document, whether the XML viewer sends your data anywhere, and whether it can check a document against a schema.

What is the difference between well-formed and valid XML?

Well-formed means the document follows XML syntax rules: one root element, closed and correctly nested tags, quoted attributes, and escaped special characters. Valid means it is well-formed and also conforms to a schema (a DTD or XSD) that defines the allowed elements and structure. A document can be well-formed without being valid, but it cannot be valid without first being well-formed.

Why does my ampersand cause a not-well-formed error?

In XML, a bare & begins an entity reference, so the parser expects something like & or & to follow. A lone ampersand in text content breaks that expectation. Escape it as &, or wrap the surrounding text in a CDATA section if it contains many special characters.

Does the XML viewer send my data anywhere?

No. The XML viewer formats and checks your XML directly in your browser, so the content is never stored on a server. It also blocks DOCTYPE and external entities, so viewing untrusted XML stays safe.

Can it check my XML against a schema?

No. The Static.app XML viewer checks well-formedness only: it confirms the syntax is correct and formats the document for easy reading. Full schema validation against a specific DTD or XSD is a separate step. Getting the document well-formed first is the prerequisite, since a schema validator cannot check a file the parser cannot even load.