XML Validator

An XML validator reads a document and answers a single, narrowly scoped question: is this text well-formed XML that any conformant parser will be able to accept? That is a structural question, not a semantic one. The validator does not know whether your price element should be positive, whether a user element ought to have an email, or whether a feed conforms to a particular publisher's editorial rules. It checks the layer that has to hold before any of those higher-level checks can even begin.

Why "well-formed" is a precise term

The W3C XML specification defines well-formedness as a fixed list of constraints: a single root element, every opening tag has a matching close, elements nest without crossing, attribute values are quoted, special characters are escaped, and the file declares a known encoding. A document that breaks any one of those rules is, by definition, not XML — even if it looks similar. The validator's job is to enforce that definition mechanically so disagreements never come down to "it parsed in my editor".

The well-formedness rules the validator enforces

Knowing which rule failed makes the error message useful. Each of the items below maps to a class of failures that an XML parser will refuse to recover from.

• Exactly one root element. A document with two top-level siblings is not XML, even if each subtree is individually well-formed.
• Every start tag has a matching end tag, in the same case, in the right place: Item open and Item close must match exactly, not Item open with item close.
• Elements nest without crossing: b containing i containing text containing close-i containing close-b is fine; crossing the closes is not.
• Attribute values are always quoted with matching single or double quotes. An attribute without quotes around its value is not allowed.
• Special characters are escaped inside text and attributes: ampersand becomes &, less-than becomes <, and stray quote marks inside an attribute value use " or '.
• The encoding declared at the top of the file (or assumed via BOM or HTTP header) actually matches the byte content. A UTF-8 file declared as ISO-8859-1 will fail on the first non-ASCII byte.

Rule of thumb: fix the first reported error before chasing later ones. A single unclosed tag near the top almost always produces a cascade of misleading errors further down.

How to use this tool

1. Prepare representative XML documents, feeds, and copied markup blocks that need structural validation in XML Validator instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate a validity result with the first XML structure problem highlighted for review, and review closing tags, nesting order, attributes, escaping, namespaces, and whether the copied text is truly XML instead of HTML-like markup before deciding the result is ready.
3. Only copy or download the result after it fits feed debugging, config review, import QA, and support triage and no longer conflicts with this constraint: Well-formed XML is only the first gate; schema or application-specific meaning still has to be checked elsewhere.

XML Validator example

This XML Validator example uses representative XML documents, feeds, and copied markup blocks that need structural validation and shows the resulting a validity result with the first XML structure problem highlighted for review, so you can confirm closing tags, nesting order, attributes, escaping, namespaces, and whether the copied text is truly XML instead of HTML-like markup before applying the same settings to real input.

Sample input

<item><name>ToolKit</name></item>

Expected output

Valid XML; root element: item

Four common failures and what the validator says

A) unclosed tag
  <book><title>XML in a Nutshell<author>Eckstein</author></book>
  -> end tag "book" found, but "title" is still open

B) crossed nesting
  <b><i>important</b></i>
  -> end tag "b" does not match the currently open "i"

C) unquoted attribute
  <a href=https://example.com>link</a>
  -> attribute value must be quoted

D) bare ampersand
  <title>Lock & Key</title>
  -> entity reference must end with ";"; did you mean &amp; ?

Notice that all four errors live at the structural layer. None require knowing what the document is about — only how XML wants tags, attributes, and entities to be written.

Where running an XML validator pays off

Validation is most useful at the moment a file is about to leave your hands. Once a malformed XML document is in a feed, an import pipeline, or a partner's inbox, fixing it costs an order of magnitude more than catching it at the source.

• Before publishing an RSS or Atom feed — readers and indexers stop trusting feeds that occasionally fail to parse.
• Before posting an XML payload to a SOAP service or partner API where the server gives only "parse error" with no line number.
• After hand-editing a configuration file (Spring, Maven, Ant, Tomcat) where a missing close tag silently breaks the next deploy.
• When a generated XML export looks fine in a browser but is rejected by a strict importer — validation rules out the structural layer first.
• When debugging an Office Open XML or SVG file, where one malformed element near the start usually blocks everything downstream.

Things well-formedness alone cannot tell you

Passing well-formedness only means the document can be parsed. Whether the parse tree is what the consumer expects is a separate question with its own tools. Knowing the boundary saves a lot of "but it validates!" debates.

• Schema validation (DTD / XSD / RELAX NG) checks element names, allowed children, attribute types, and required occurrences. Well-formedness ignores all of those.
• Namespace correctness: a document can be well-formed and still use the wrong namespace URI, which makes downstream lookups silently miss every node.
• Business invariants — a price element being positive, a date being in the past — never appear in XML's notion of validity at all.
• Whitespace inside mixed-content elements is significant to readers but not to validators; the document may parse but render differently than expected.
• Very large documents may fall over on entity expansion (billion laughs) regardless of well-formedness — security review and parser hardening are separate concerns.

Well-formedness vs adjacent XML checks

Practical Notes

• Review closing tags, nesting order, attributes, escaping, namespaces, and whether the copied text is truly XML instead of HTML-like markup before you reuse the a validity result with the first XML structure problem highlighted for review.
• Well-formed XML is only the first gate; schema or application-specific meaning still has to be checked elsewhere.
• Keep the original XML documents, feeds, and copied markup blocks that need structural validation available when the result affects production work or customer-visible content.

XML Validator reference

XML Validator reference content should stay anchored to XML documents, feeds, and copied markup blocks that need structural validation, the generated a validity result with the first XML structure problem highlighted for review, and the checks needed before feed debugging, config review, import QA, and support triage.

• Input focus: XML documents, feeds, and copied markup blocks that need structural validation.
• Output focus: a validity result with the first XML structure problem highlighted for review.
• Review focus: closing tags, nesting order, attributes, escaping, namespaces, and whether the copied text is truly XML instead of HTML-like markup.

References

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax
• W3C: Extensible Markup Language (XML) 1.0