Validate XML is a free online tool that checks whether an XML document is well-formed and, when you provide a schema, performs structural validation against it. Well-formedness is checked with the browser's native DOMParser — the same engine that powers XML parsing across the web platform — and schema checking compares every element name in your document against the elements declared in an XSD you paste alongside it.
XML validity comes in two distinct, commonly confused levels. "Well-formed" means the document obeys XML's own baseline syntax rules regardless of what it is supposed to contain: exactly one root element, every opening tag has a matching closing tag (or is self-closed), tags are properly nested without overlapping, attribute values are quoted, and reserved characters like &, <, and > are escaped as entities (&, <, >) wherever they appear as literal text rather than markup. Any XML parser — a browser, a build tool, an API client — can reject a document at this level without knowing anything about what the document is meant to represent. "Valid" is a stricter, additional claim: the document is well-formed AND it conforms to a specific schema (a DTD or an XSD) that defines exactly which elements and attributes are permitted, in what order, and with what data types. A document can be perfectly well-formed and still invalid — for example, a "well-formed" invoice XML with a <total> element containing the text "banana" is syntactically fine but violates a schema that requires <total> to be numeric.
Browsers, this one included, do not ship a full XSD validation engine — that requires the kind of complete implementation found in dedicated libraries like Xerces or Saxon, supporting complex types, type inheritance, facets, and namespace-aware schema resolution. What this tool provides instead is a practical, fast, structural check: it extracts every element name declared in your pasted XSD and confirms every element actually used in your XML document appears in that declared set, catching the most common real-world mistake — a typo'd tag name, a leftover element from an old schema version, or a namespace prefix mismatch — without requiring a server-side validation library. For anything requiring full facet-level, type-strict XSD conformance (say, before submitting to a government or banking XML interchange format with a strict published schema), a dedicated command-line validator like xmllint remains the authoritative tool.
This kind of check matters most in a handful of recurring situations: verifying a SOAP request envelope is syntactically sound before it hits a web service that will reject anything malformed with an opaque fault, catching a broken closing tag in a hand-edited configuration file (Android manifests, Maven POMs, and Spring bean definitions are all XML and all suffer from this), sanity-checking an exported data feed before importing it into another system, and confirming an API response actually matches the XML shape your integration code expects before you spend time debugging a parser exception further downstream.
Everything runs locally using the browser's native XML parser — no XML or XSD content is ever uploaded anywhere, which matters when the document you are validating is an internal configuration file, a contract, or another document you would rather not send to a third-party service.
Just need clean, readable indentation rather than schema validation? Format XML handles that lighter case.
