XML Validator
Check XML well-formedness and inspect roots, namespaces, declarations, DOCTYPE, attributes, CDATA, and schema hints.
This checks an XML document with one document element. A fragment with several top-level elements needs a wrapper before it becomes a well-formed XML document.
XML parser status, root/namespace information, declaration, DOCTYPE, schema hints, and document statistics will appear here.
Well-Formed XML and Valid XML Are Different Claims
Well-formedness is the XML language baseline: one document element, properly nested and case-matched tags, quoted attribute values, legal character references, valid namespace bindings, and syntax that an XML parser can build into a document tree.
Validation adds another layer. A DTD or XML Schema can say that a book must contain a title, that an attribute has a particular type, or that elements must occur in a specific order. This browser checker answers the first question. It does not pretend to answer the second without the schema and a validating processor.
XML Has One Document Element—A Fragment Is Not Automatically a Document
Not an XML document: <item>A</item> <item>B</item> Wrapped as one document: <items> <item>A</item> <item>B</item> </items>
Editors and APIs sometimes talk about “XML fragments” that contain several sibling nodes. That can be valid application data, but an XML document itself has one root/document element. The check here uses document form.
Namespace Prefixes Are Labels; Namespace URIs Carry the Identity
x:price and p:price can represent the same expanded XML name when x and p are bound to the same namespace URI. Conversely, identical local names under different namespace URIs are different names to namespace-aware software.
The report therefore shows namespace URIs separately from prefixes. Debug schema failures by checking the URI actually bound to the element, not by assuming a familiar prefix has universal meaning.
A Default Namespace Does Not Automatically Apply to Unprefixed Attributes
In Namespaces in XML, a default namespace applies to unprefixed element names, but the namespace name for an unprefixed attribute is not taken from that default namespace. This surprises developers moving between element and attribute APIs.
If an XSD or application expects a qualified attribute, inspect its namespace URI rather than assuming it inherited the element's default namespace.
The encoding="UTF-8" Declaration Cannot Be Verified After the Bytes Are Already a JavaScript String
Character encoding is a byte-to-character question. By the time text is pasted into this page, the browser has already produced a JavaScript Unicode string. DOMParser does not receive the original file bytes alongside the declaration.
The validator can inspect what the declaration says, but it cannot prove a file claiming UTF-8 was actually encoded as UTF-8 on disk or over HTTP. When mojibake or encoding mismatch is the problem, inspect the original bytes and transport Content-Type as well.
XML 1.0 Does Not Permit Every Control Character
XML 1.0 defines a specific character range. Common tab, line feed and carriage return are allowed, but many other C0 control characters are not legal XML 1.0 characters even when a JavaScript string can contain them.
Yoryantra performs a source-character scan before DOM parsing so a hidden control character has a clearer line/column clue instead of being reduced to an opaque generic parser failure.
DOCTYPE and Entity Handling Are a Security Boundary in Server-Side Parsers
DTDs can declare entities and external identifiers. Historically, unsafe server-side XML parser configurations have allowed external entity expansion to read local resources, perform network requests, or consume excessive resources.
This browser's DOMParser behavior is not evidence that a Java, PHP, Python, .NET, C/C++, or backend library is configured safely. When your application does not require DTDs/external entities, disable unnecessary external entity and external DTD processing using that parser's security controls.
schemaLocation Is a Hint; It Does Not Perform XSD Validation
Attributes such as xsi:schemaLocation can associate namespace names with schema locations, while xsi:noNamespaceSchemaLocation can point at a schema for unnamespaced content. Seeing those attributes only tells you the hint exists.
The browser review does not download the XSD, resolve imports/includes, or validate types and content models. Use an XSD validator that understands the exact schema set when application validity matters.
CDATA Avoids Markup Recognition Inside the Section; It Is Not “Raw Anything”
A CDATA section lets text contain characters such as < and & without treating them as ordinary markup or entity-reference starts. But the section itself still has XML syntax and cannot contain its terminating ]]> sequence as content.
CDATA also does not change the meaning of the resulting character data to downstream applications. It is a source representation choice, not a validation bypass.
XML Is Not HTML With Stricter Formatting
XML element names are case-sensitive, arbitrary empty elements can use />, and HTML's large set of named character entities is not automatically available. XML's predefined entities are limited unless a DTD defines more.
A browser's forgiving HTML parser may repair markup that an XML parser correctly rejects. When an API says it accepts XML, test it as XML rather than opening it as text/html and assuming the repaired DOM proves validity.
A Well-Formed Sitemap, SVG, SOAP Envelope, or Config File Can Still Be Wrong for Its Application
Sitemap protocol limits, SVG element semantics, SOAP namespaces, Maven/Android/application configuration schemas, and proprietary API contracts all live above generic XML syntax. The root element can be spelled perfectly while the consuming system rejects the document for a missing required child or wrong namespace version.
Use the well-formedness result to answer “can an XML parser build the document?” Then move to the application-specific validator for “is this the right XML document?”
Defines XML documents, well-formedness constraints, character ranges, declarations, elements, attributes, comments, CDATA, DTDs and entity syntax.
Defines qualified names, prefixes, namespace declarations, namespace names and default-namespace behavior.