UtilitiesHub

XML Validator

Validated output


Explore More

Go straight to the formatter, validator, encoder, generator, or developer utility you need.

Coding Tools

XML Validator — Check XML Well-Formedness and Find Syntax Errors Online

XML is an unforgiving format. Unlike HTML, where browsers will silently attempt to recover from bad markup — closing tags automatically, ignoring unrecognized attributes, rendering content despite structural errors — XML parsers operate on a strict pass/fail basis. A single syntax violation anywhere in an XML document causes the entire document to be rejected. No partial processing, no recovery attempts, no guesswork. The parser stops at the first error and reports a failure. This strictness is intentional: it's what makes XML reliable for data exchange between systems. But it means that before you use an XML document — submitting it as an API payload, serving it as a sitemap, committing it as an application configuration file, or sending it in a SOAP envelope — you need to be certain it's syntactically valid.

This free online XML validator parses your document entirely in the browser using the browser's native XML parser. No data is sent to any server. Paste your XML and get an immediate result: either a confirmation that the document is well-formed, or a precise error message identifying exactly what's wrong and where — the element name, line number, and character position. Well-formed documents can also be instantly formatted for easier reading.

Well-Formed vs. Valid XML — A Distinction That Matters

These two terms are frequently confused, and the difference is important for understanding what this validator does and what it doesn't do.

Well-formed XML means the document conforms to the fundamental syntax rules of the XML specification. These rules don't depend on any schema — they apply to every XML document regardless of its purpose or structure. A well-formed document: has exactly one root element, has all opening tags matched by closing tags, has all elements properly nested without overlap, has all attribute values quoted (with either single or double quotes), uses only valid XML characters, escapes reserved characters in text content (using entity references like &amp; for &, &lt; for <), and has no content before the XML declaration if one is present.

Valid XML goes further — it means the document is both well-formed and conforms to a specific schema, defined either as a DTD (Document Type Definition) or an XSD (XML Schema Definition). Schema validation checks structural correctness: are the right elements present, in the right order, with the right attributes, containing values of the correct data type? A document can be perfectly well-formed but structurally invalid — it follows syntax rules but doesn't match the expected format. This tool checks well-formedness, which is the necessary first step. Schema validation requires the schema file and is typically done with tools like xmllint, Oxygen XML, or XMLSpy.

The Most Common XML Syntax Errors — and How to Fix Them

Understanding the most frequent error patterns makes fixing XML much faster. Here are the errors that come up most often:

Unclosed tags: Every opening tag (<item>) must have a matching closing tag (</item>). Self-closing shorthand (<item />) is valid for empty elements. A missing closing tag causes an error that points to the end of the document rather than the unclosed element itself, which can be confusing.

Improper element nesting: Elements must be properly nested — a child element must close before its parent closes. <a><b></a></b> is invalid because <b> is still open when </a> appears. The parser catches this as a mismatch between the element that was opened and the closing tag it encounters.

Unescaped reserved characters in text: The characters <, >, and & have special meaning in XML markup. If they appear in text content (rather than as markup), they must be escaped: < becomes &lt;, & becomes &amp;. This is the most common error for developers copying content from other sources into XML elements.

Using HTML entities in XML: HTML has a large set of named entities like &nbsp;, &copy;, and &eacute;. None of these are defined in base XML. XML only recognizes five predefined entity references: &amp;, &lt;, &gt;, &apos;, and &quot;. Any other entity reference must be declared in a DTD. Developers who copy HTML content into XML frequently encounter "undefined entity" errors because of this difference.

Unquoted attribute values: In HTML, some parsers tolerate unquoted attribute values. XML requires all attribute values to be quoted, with either single or double quotes. <element attr=value> is invalid XML; it must be <element attr="value"> or <element attr='value'>.

Where XML Validation Is Most Critical in Real Development

XML sitemaps: Google Search Console requires sitemaps to be well-formed XML. A sitemap with a single syntax error is rejected entirely — no URLs in the file are submitted for indexing. Validating your sitemap before submission is a simple step that prevents a potentially significant SEO problem from going unnoticed.

SOAP web services: SOAP messages are XML documents wrapped in an Envelope/Body structure. A malformed SOAP request returns a Fault response before any application logic runs. Enterprise integrations with banking systems, payment processors, government services, and legacy platforms that use SOAP all require valid XML — and debugging a SOAP error is much easier when you've validated the message structure before sending.

Application configuration files: Spring application contexts, Maven pom.xml files, ANT build files, and many enterprise framework configurations are XML. A syntax error in any of these files causes a build failure or application startup error. Catching the error in a validator before committing or deploying is much faster than diagnosing a cryptic runtime exception.

Android layout files: Android user interfaces are defined as XML. A syntax error in a layout file causes a build error. While Android Studio provides inline validation, when working with externally generated or modified layout files, validating them before importing is a useful sanity check.

Data exchange and feeds: RSS feeds, Atom feeds, OpenSearch descriptions, and XML-based data exports all require valid XML for consuming applications to parse correctly. A broken feed can cause silently missing content in aggregators or errors in automated data pipelines.

Frequently Asked Questions About XML Validation

This tool validates well-formedness — whether the XML follows correct syntax rules. It does not perform schema validation against an XSD or DTD. For schema validation, you need a tool that accepts both the XML document and the schema file, such as xmllint --schema schema.xsd document.xml on the command line, or a dedicated XML IDE like Oxygen XML or XMLSpy.
No. Validation runs entirely in your browser using JavaScript's built-in DOMParser. Your XML is never sent to any server. This means you can safely validate XML containing sensitive configuration data, internal API responses, or proprietary data structures.
Your XML is well-formed (syntactically correct) but may not be schema-valid (structurally correct per the application's expected format). Many applications validate against an XSD schema beyond basic well-formedness — checking required elements are present, element order is correct, attribute values match allowed patterns, and data types are appropriate. Passing this validator means the syntax is correct; the application may additionally require schema-level correctness.
XML has five predefined entity references: &amp; (&), &lt; (<), &gt; (>), &apos; ('), and &quot; ("). Using any other entity reference (like the HTML entities &nbsp; or &copy;) in XML requires them to be declared in a DTD first. If you've copied HTML into your XML, these undeclared entities will cause a parse error. Replace them with their character equivalents or Unicode escape sequences.
Yes. After validation passes, you can format the XML for readable output. Formatting only works on valid XML because the formatter works from the parsed document object — if parsing fails, there's no document to format. The workflow is: validate first, then format the valid result.
Paste your sitemap XML here to check well-formedness first. Then verify it follows the sitemap protocol — a <urlset> root element with the correct namespace (xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"), and <url> children each containing at minimum a <loc> element. Google Search Console also validates sitemaps on submission and reports specific errors if the format doesn't match the sitemap schema.
The XML declaration (<?xml version="1.0" encoding="UTF-8"?>) is the first line of an XML document and declares the version and character encoding. It's technically optional for UTF-8 documents but strongly recommended. It must appear as the very first line — even a blank line before it will cause some strict parsers to fail. If your XML is being rejected with an error about the prolog or document start, check that nothing precedes the declaration.