Validate XML Online

How to Validate XML Online

1. Paste or Upload Your XML: Paste XML into the input editor, drop an .xml file onto the page, or click "Add Files" to load one from disk. Files stay in your browser session — no upload, no account, no logging.
2. Click "Validate": The parser checks your document against the W3C XML 1.0 (Fifth Edition) well-formedness rules — proper nesting, matched start/end tags, quoted attribute values, single root element, escaped reserved characters, declared entities, and unique attribute names per element.
3. Read the Result Panel: A green "Well-formed" badge means every constraint passed. A red error shows the exact line and column of the first failure with a human-readable message (e.g., Opening and ending tag mismatch: item line 12 and items, line 15, column 9).
4. Fix and Re-Validate: Edit directly in the editor, click Validate again, and repeat until clean. Then copy the cleaned XML, download it, or feed it into XConvert's XML to JSON or XML to YAML tools.

Why Validate XML?

XML has strict syntax rules: every start tag needs a matching end tag, every attribute value must be quoted, every document has exactly one root element, and five characters (<, >, &, ', ") must be escaped when they appear in text. A single missed & or unclosed <item> makes the entire document unparseable — and parsers usually report the error several lines after the actual mistake, which is why a dedicated validator with line and column pointers saves real debugging time.

• Debug SOAP and REST-XML responses — When a SOAP fault or XML-RPC reply looks broken, validate it before assuming the API is at fault. A well-formed XML body with an error payload is fundamentally different from a truncated or malformed response, and the fix lives in opposite places.
• Catch config-file typos before they crash an app — Java EE web.xml, Maven pom.xml, Tomcat server.xml, Spring applicationContext.xml, and Android AndroidManifest.xml all refuse to load on a single unclosed tag. Validating after a hand-edit catches the typo in five seconds instead of after a redeploy.
• Verify RSS, Atom, and sitemap feeds before publishing — Feed readers and search-engine crawlers silently drop malformed feeds. Google Search Console specifically rejects sitemaps that aren't well-formed XML, so a validation pass before submitting saves a re-crawl cycle.
• Sanity-check SVG before embedding — SVG is XML under the hood. Browsers are forgiving with HTML but strict with standalone SVG; an unclosed <path> or an unescaped & in a <text> element makes the file render blank.
• Prep XML for conversion or XSLT — Malformed input produces undefined output. Validate before running an XSLT transform or piping through XML to JSON — it eliminates "garbage in" as a debugging variable.
• Industry interchange — HL7 CDA (healthcare), XBRL (financial reporting), DITA and EPUB (publishing), and FIXML (trading) all require well-formed XML at the perimeter. Regulators and clearinghouses reject documents that fail at the parser stage before any business-rule validation runs.

Well-Formed vs Valid — The Canonical XML Distinction

These two terms get conflated constantly, but the W3C draws a hard line between them. XConvert's validator checks well-formedness. Schema validation against a specific DTD or XSD is a separate, downstream step.

Aspect	Well-Formed	Valid
What it checks	XML syntax only	Conformance to a specific schema (DTD/XSD/RelaxNG)
Required for parsing?	Yes — non-well-formed XML cannot be parsed at all	No — a parser can read well-formed XML without any schema
Needs a schema?	No	Yes (DTD, XSD, or RelaxNG referenced or supplied)
Catches typos?	Yes (unclosed tag, bad quote, bad entity)	Yes, plus structural errors ("element <price> not allowed here")
Catches data-type errors?	No	Yes ("age must be an integer, got twelve")
Errors are...	Fatal — processor must stop (W3C spec)	Reportable — processor may continue per its mode
W3C term	"Well-formedness constraint" (WFC)	"Validity constraint" (VC)
Every valid doc is also...	well-formed	(no — well-formed does not imply valid)
XConvert checks this?	Yes	No (use a schema-aware tool like xmllint --schema or Oxygen XML)

Common Well-Formedness Errors and How to Fix Them

These are the failures the validator catches most often, in roughly descending frequency:

Error	Example	Fix
Unescaped & in text	<note>Tom & Jerry</note>	<note>Tom &amp; Jerry</note> — & always escapes to &amp; outside CDATA
Mismatched start/end tag	<Item>...</item>	XML is case-sensitive; match exact casing
Unclosed tag	<row><cell>1<cell>2</row>	Close every element: <cell>1</cell><cell>2</cell>
Multiple root elements	<a/><b/> at top level	Wrap in a single root: <doc><a/><b/></doc>
Unquoted attribute value	<img src=photo.jpg/>	Quote with " or ': <img src="photo.jpg"/>
Undeclared namespace prefix	<soap:Envelope>... without xmlns:soap="..."	Declare on the root: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
Duplicate attribute	<a href="x" href="y"/>	Each attribute name may appear once per element (WFC: Unique Att Spec)
Invalid character in content	A literal < in text content	Escape to &lt;, or wrap the chunk in <![CDATA[...]]>
Double-hyphen inside comment	<!-- a -- b -->	Comments may not contain --; rewrite or split
Bad XML declaration position	<?xml version="1.0"?> after blank lines or a BOM	The declaration must be the very first thing; strip leading whitespace and BOM if needed
Lone surrogate / invalid char ref	&#xD800;	Character references must match the XML Char production — control bytes and unpaired surrogates are illegal
Wrong encoding declaration	File saved as UTF-16 but declared encoding="UTF-8"	Match the actual file encoding, or remove the declaration and let the parser sniff the BOM

Frequently Asked Questions

Does this tool validate against a DTD or XSD schema?

No — it checks well-formedness only, which is the W3C XML 1.0 syntax layer. Schema validation needs the schema itself (DTD, XSD, or RelaxNG) and a schema-aware parser. For XSD validation, xmllint --schema schema.xsd file.xml is the standard free option; Oxygen XML Editor handles all three schema languages. A document must be well-formed before any schema check can run, so validating here first eliminates a whole class of errors before you reach for a heavier tool.

What's the practical difference between "well-formed" and "valid"?

Well-formed means the document follows XML syntax — tags nest, attributes are quoted, & is escaped, there's one root. Valid means it also matches a schema that defines which elements are allowed where and what data types they hold. A document that says <book><price>twelve</price></book> is well-formed (the syntax is fine) but invalid against a schema that requires <price> to be a decimal. XConvert catches the first kind of error; you'll need a schema-aware validator for the second.

Why does my XML fail on a & inside text?

In XML, & always starts an entity reference. A raw & in text content (or inside an attribute value) is a fatal well-formedness error per the W3C spec — even when you meant it as the word "and." Replace it with the predefined entity &, or wrap the offending text in <![CDATA[ ... ]]>. The same applies to < (use <); >, ", and ' are technically optional in most contexts but escaping them never hurts.

Can it validate SOAP, SVG, RSS, or Atom specifically?

Yes — all four are XML, so well-formedness checking applies. SOAP envelopes, SVG vector graphics, RSS 2.0 / Atom 1.0 feeds, XML sitemaps, EPUB OPF files, DocBook, DITA, and HL7 CDA all parse through the same well-formed-XML gate. XConvert won't tell you whether your SOAP envelope conforms to the WS-I Basic Profile or whether your RSS uses the right element names — that's schema validation — but it will flag the unclosed <channel> or unescaped & that's making the document unparseable.

How does CDATA affect validation?

Content inside <![CDATA[ ... ]]> is treated as literal characters — XML markup rules don't apply, so raw <, >, and & are allowed there. The validator still checks that the CDATA section itself is properly opened and closed and that it doesn't contain the literal ]]> sequence (which would close it prematurely). CDATA is the standard way to embed JavaScript inside XHTML or to pass HTML fragments through an RSS <description> without escaping every character by hand.

Do I need an <?xml version="1.0"?> declaration?

It's strongly recommended but technically optional for XML 1.0 documents that use the default UTF-8 / UTF-16 encoding. If you include it, it must be the very first thing in the file — no blank lines, no leading whitespace, no UTF-8 BOM in front of it on parsers that don't strip BOMs first. For XML 1.1 the declaration is mandatory because the version differs from the default.

Why does the parser report an error on line 50 when my mistake looks like it's on line 30?

XML parsers report the position where parsing became impossible, not where you made the mistake. An unclosed <section> on line 30 only becomes a fatal error when the parser hits the next </section> or document-end on line 50 and can't reconcile the stack. The fix lives upstream of the reported line — walk backward through your open elements and look for the mismatch.

Is my XML data sent to a server?

No. The validator runs entirely in your browser using a client-side parser — your document never leaves the page session. That matters for web.xml, applicationContext.xml, or any file containing connection strings, API keys, internal hostnames, PHI/PII, or unreleased pricing — none of it crosses the network.

What's the biggest file I can validate?

The hard limit is your browser's available memory rather than any XConvert-imposed cap. Most modern desktop and mobile browsers handle XML files up to a few tens of megabytes without trouble. For multi-hundred-megabyte XBRL filings or large XML database dumps, a streaming command-line tool like xmllint --noout file.xml is the right shape — browser-based DOM parsing isn't designed for that scale.

Can I validate XHTML or HTML with this?

XHTML 1.0 / 1.1 — yes, because XHTML is XML by spec. Plain HTML5 — no; HTML5 deliberately tolerates unclosed tags, unquoted attributes, and unescaped & in many positions, so almost any non-trivial HTML5 page will fail well-formedness. Use the W3C Nu HTML Checker for HTML5, and validate XHTML / SVG / MathML here.

What happens after my XML passes validation?

You're cleared to feed it into anything that expects well-formed XML — an XSLT transform, an XPath query, a parser in any language, or a format converter. Common next steps on XConvert: XML to JSON for working with modern REST APIs, XML to YAML for configuration files, or Validate JSON and Validate YAML when you need to check the other side of a pipeline.