Free XML Validator - Well-Formed Documents, Not XSD

XML has two famous adjectives that people collapse into one word, "valid." Well-formed is a nesting and quoting rule: tags close in order, attribute values are quoted, there is a single root, and the document is usable as a tree. Schema-valid means that tree also matches an XSD, Relax NG, or DTD contract - required elements, types, enumerations, identity constraints. This page only does well-formedness. The default <root></root> is well-formed. <root> is not. <root><a></root> is not, because a never closes.

Browsers do not ship a complete XSD 1.1 processor in JavaScript. Loading external DTDs from a webpage would be an XXE-style hazard: the parser might fetch network resources you did not intend to contact. This tool therefore only uses DOMParser with application/xml and reads a parsererror node. That limit is documented on purpose. If a vendor page promises in-browser XSD 1.1 for arbitrary schemas, read the fine print.

On the server, DOMParser is often missing. The function guards typeof DOMParser === "undefined" so server rendering does not throw. The real check runs in the browser after hydration. You should judge the result in a client, not in an SSR log.

Namespaces are preserved as attributes. A prefix that looks right is not proof that it matches the schema you had in mind. Convert a well-formed tree on XML to JSON once the document actually parses.

The workflow is a parse, not a schema compile:

1. Paste XML - Drop a SOAP snippet, an RSS fragment, or a config file into the left panel. Click Sample to restore <root></root>.
2. Read well-formed or the parser error - <root> without a close fails. <root><a></root> also fails. The browser exposes a parsererror node; this page prints that text.
3. Do not expect schema validation - XSD and DTD are not applied. A document can be well-formed and still violate a purchase-order schema you keep in another repo.
4. Copy or clear - Copy the report. Clear erases the editor and the draft under xml-validator-input.

Resize uses the unique class xml-validator-split-track so this layout cannot steal the JavaScript validator's handle. Fullscreen is for long parser messages. Width is stored in xml-validator-panel-width.

HTML allows unquoted attributes and implicit closes in many cases. XML does not. If you paste an HTML fragment, expect failures that a browser tab would "fix." That is a feature when you are debugging SOAP or SVG-as-XML.

• Unclosed or crossed elements. <a><b></a> is illegal. Close b first.
• Multiple roots. <a/><b/> is a fragment, not a document.
• Unquoted attributes. <a href=foo> may be HTML. XML wants quotes.
• Raw ampersands. & in text must be escaped as & unless it starts a well-known entity the parser accepts.
• Mismatched case. <Root></root> is not the same name. XML is case-sensitive.
• Invalid characters in names or a missing XML declaration that some producers emit as a broken first line. The declaration is optional; a truncated one is not.

An XML declaration such as <?xml version="1.0" encoding="UTF-8"?> is optional for well-formedness in UTF-8 documents. A truncated declaration - a missing closing ?> - is not optional; it is a parse error. Encoding labels in the declaration are a contract with the bytes on disk. In a browser textarea you are already in Unicode. Pasting Latin-1 bytes that were decoded wrong will show replacement characters before the parser ever runs. Fix the paste, then check well-formedness.

CDATA sections let you include raw < and & in character data. They must close with the CDATA terminator. An unclosed CDATA block is a well-formedness failure. Processing instructions and comments have their own close delimiters. HTML comments that contain -- in the middle can be illegal in XML comments. If you paste HTML-as-XML, those comment rules are a frequent surprise.

Empty elements may be written <root></root> or <root/>. Both are well-formed. Mixed content - text and elements as siblings - is well-formed XML and very common in documents. Schema types might forbid mixed content; this page will not. Whitespace between elements is character data in the DOM even when you think of it as "just formatting."

Browser parsererror text is implementation-defined. Firefox and Chromium word the same nesting bug differently. This tool prints whatever the engine put in the error node. It does not re-implement a second XML 1.0 spec in JavaScript. If you need byte-identical diagnostics across machines, use xmllint or an XML library in CI. Use this page for a fast, honest well-formedness gate while you edit.

SVG-in-HTML and SVG-as-XML are different parsing modes. An SVG file you open as XML must be well-formed. The same markup inlined in HTML is parsed by the HTML parser, which is more lenient. If your asset pipeline treats SVG as XML (many do), validate it here. If it is only inline in a React component as JSX, you are in a different language again - JSX is not XML, even when it looks similar.

SOAP envelopes are XML with a required structure defined by a namespace and a WSDL. You can still fail the envelope before you fail the contract: a truncated Body, an unescaped payload inside a string that was meant to be nested XML, or a namespace prefix that never bound. This page catches the truncation. It will not tell you that GetQuote is the wrong operation name. Take a well-formed envelope to a SOAP client or a schema tool next.

RSS 2.0 and Atom are XML feeds. Aggregators vary in how much they recover. A missing </item> can drop the rest of the feed in a strict parser and look like "the blog stopped publishing." Paste the XML source, not the rendered HTML of the post. HTML from a browser "view source" on the article page is the wrong artifact.

SVG as a standalone file is XML. Tools that optimize paths, strip metadata, or merge sprites sometimes emit malformed files - duplicate xml declarations, unescaped ampersands in titles, or a missing root close after a bad concat. Design tools that export SVG for the web sometimes emit HTML-ish attributes. If your build inlines SVG as XML (React dangerouslySetInnerHTML is a different, riskier path), well-formedness is the first check.

Android strings.xml, Maven POMs, and Office Open XML parts are also XML. A bad merge conflict marker inside a POM is not well-formed. Conflict markers are not XML comments. Remove them, then re-check. Schema-valid POM structure is still Maven's job.

JSON is not XML. If you pasted an API body that starts with {, you are on the wrong tool - use the JSON validator. YAML is not XML either. Well-formedness will fail immediately on significant indentation without tags, which is the correct answer.

Character references such as   and named entities the XML spec requires (<, >, &, ', ") belong in well-formed documents. HTML named entities like   are not part of XML unless a DTD defines them - and this page will not load that DTD. If a document relies on HTML entities, convert them to numeric character references or to UTF-8 characters before you call it XML.

Parsing stays in the browser. Drafts use the unique key xml-validator-input for up to 30 days. Panel width uses xml-validator-panel-width. Clear deletes the source. External DTDs are not loaded, which is both a privacy choice and an XXE mitigation.

XML can still contain secrets in element text. Do not paste production payloads with credentials onto a shared machine. The tool will not upload them; the person looking over your shoulder might still read them.