Well-Formed XML vs Valid XML: What Validation Proves

Four different questions hidden behind “Is this XML valid?”

Teams often use valid to mean several things. That shorthand becomes dangerous when two people believe the same green indicator represents different evidence. Separate the question into four layers:

1. Well-formed syntax: can an XML processor construct one document according to XML's core grammar and well-formedness constraints?
2. Grammar or schema validity: does the document conform to the particular DTD, XSD, Relax NG grammar, Schematron rule set, or other contract selected for this exchange?
3. Application correctness: do identifiers exist, totals reconcile, state transitions make sense, references resolve, and business permissions allow the requested action?
4. Security and provenance: is the sender authenticated, is the signature valid under the required canonicalization rules, is the content authorized, and is every parser configured safely?

A browser syntax checker can provide evidence for the first layer. It cannot infer the other three from markup alone. A production acceptance pipeline may need all four, with different tools and trust inputs at each stage.

What well-formed XML means

The W3C XML 1.0 specification defines the document grammar and named well-formedness constraints. A conforming document has exactly one root, or document, element. Tags nest rather than cross, element and attribute names are legal, attribute values are quoted, entity references have permitted forms, and reserved markup characters appear only where XML grammar allows them.

<order id="o-42">
  <customer>Ahn &amp; Lee</customer>
  <item quantity="2">B-17</item>
</order>

This document has one root element, its child tags close in order, the attribute values use quotes, and the ampersand in text is escaped. Those facts say nothing about whether order is an allowed root, whether quantity must be an integer, or whether customer Ahn & Lee may order item B-17.

<order>
  <customer>Ahn
</order>
  </customer>

<customer>
  Ahn & Lee
</customer>

XML names are case-sensitive: <Item></item> does not match. An empty element may use <item/>. Comments cannot contain the forbidden double-hyphen sequence, and CDATA closing syntax cannot occur as ordinary CDATA content. Namespace prefixes must be declared in scope according to Namespaces in XML.

What valid XML means

In the XML 1.0 specification, a valid document is well formed, has an associated document type definition, and obeys the specification's validity constraints. The DTD describes permitted element content, attributes, entities, and notations. Validation is therefore relative to that declared grammar; there is no universal vocabulary rule that says every well-formed <order> is a valid order.

Modern systems also use W3C XML Schema Definition Language, commonly called XSD, and other languages. An XSD processor performs schema assessment against a selected schema set and can evaluate element declarations, content models, occurrences, simple data types, derived types, wildcards, and identity constraints. Relax NG expresses patterns with a different model. Schematron evaluates assertions and reports. Saying “schema-valid” should identify the language, exact schema artifacts, version, and resolution policy.

<order id="o-42">
  <quantity>many</quantity>
  <delivery-date>eventually</delivery-date>
</order>

The parser can build this tree. An XSD might require quantity to be a positive integer and delivery-date to be a date. A DTD can constrain element order and presence but does not provide XSD's built-in decimal and date type system. A Schematron rule might require a delivery date only for physical items. The same syntax receives different answers under different contracts.

Namespaces and validity are related but separate

A namespace name is an identifier, usually written like a URI, that distinguishes vocabularies. A prefix is local shorthand for that identifier. The elements a:item and b:item have the same expanded name when both prefixes are bound to the same namespace URI. Conversely, two unprefixed item elements can mean different things under different default namespaces.

Namespace well-formedness checks whether prefixes are legally declared and used. It does not prove that the namespace URI is reachable, that a schema exists at that address, or that the element is allowed by a schema. XML namespace names are identifiers rather than an automatic download instruction. Schema processors use their own import, include, catalog, and resolver policies to locate grammar resources.

Unprefixed attributes are not automatically placed in the element's default namespace. This detail causes subtle contract failures when authors assume a default namespace applies uniformly. Diagnose with expanded names—namespace URI plus local name—not only the visible prefix spelling.

A practical XML checking pipeline

Run cheaper and more universal checks before expensive or context-dependent ones. Preserve the original bytes whenever signatures, forensic evidence, or source-sensitive processing matters.

1. Establish the trust boundary. Record where the XML came from, its maximum permitted size, encoding expectations, and whether any referenced resources are allowed.
2. Configure the parser before parsing. Disable DTD processing and external entity resolution unless the protocol explicitly requires them and you have a controlled local resolution policy. Apply input, depth, node, expansion, time, and output limits.
3. Check well-formedness. Reject broken syntax without attempting a guess-based repair. Report a bounded diagnostic and location while avoiding sensitive content in logs.
4. Select an authoritative grammar. Choose the exact DTD, XSD, Relax NG, or Schematron assets by version and policy, not an untrusted location supplied by the document.
5. Validate the document. Capture the validator, versions, catalogs, imports, and errors. Avoid treating warnings as success without an explicit policy.
6. Verify signatures and provenance. Use the required canonicalization and transformation algorithms, certificate or key trust rules, replay controls, and signed-node selection defenses.
7. Apply application rules. Resolve references, authorize the actor, validate state transitions, recompute totals, and test side effects. Schema-valid data can still be fraudulent or nonsensical.

The LiveParse XML Validator deliberately covers only a local XML 1.0 well-formedness stage without DTD processing. A DOCTYPE stops its check because DTD grammar is unsupported; the validator never fetches or validates a DTD, rejects custom entity declarations and undefined named references, and does not load an XSD or other external resource. That narrow result is useful when it is labeled accurately.

DTD, external entities, and parser security

DTD and entity processing are not merely validation features; they affect resource access and expansion behavior. An external entity can point to a file or network location. A parser configured to resolve it may disclose local data, make server-side requests, or consume resources. Nested entity expansion can also exhaust memory or CPU. The OWASP XXE overview explains this vulnerability class and emphasizes disabling DTD and external entity processing when they are not required.

Disabling external resolution does not make every later use safe. XSLT engines may load documents or expose extension functions. XPath expressions can be constructed unsafely. XML deserializers can instantiate application types. SVG or XHTML rendered as active content has a browser security surface. Treat each processor as a new trust boundary with its own features and limits.

Browser parsing and rendering are different operations

The browser DOMParser API documented by MDN can parse XML-family MIME types into a document, but its error representation and availability differ by environment. A Web Worker does not share every Window API, and libraries can report errors differently. Portable tooling should define its parser contract, treat warnings deliberately, cap diagnostics, and test known malformed cases.

Parsing a string into an inert-looking document is also not permission to inject its markup into the live page. Inserting untrusted XML-derived strings through HTML sinks can activate browser interpretation. A structural viewer should render labels and values as text, as LiveParse's XML Viewer does, rather than treating the input as page markup.

Why formatting does not establish validity

An XML formatter primarily improves layout. It may parse the source first, so malformed syntax can prevent output. That parser gate establishes at most well-formedness under the formatter's supported subset; it does not select the correct schema or apply business rules.

LiveParse's formatter preserves raw tags, attribute order and quote style, self-closing spelling, supported entity-reference spellings, declarations, comments, CDATA, processing instructions, mixed-content subtrees, and inherited xml:space="preserve" regions. It changes eligible whitespace between or around markup and applies the selected line ending only to inserted structural separators. That whitespace can still affect application text nodes, byte comparisons, canonicalization inputs, and signatures. Pretty printing is not XML Canonicalization and does not verify a digital signature.

Three outcomes that should not be confused

1. Not well formed

<invoice currency="USD>
  <total>42.00</total>
</invoice>

No schema question is meaningful until the quote boundary is repaired. A strict XML processor cannot reliably construct the intended attribute and element tree.

2. Well formed but invalid under the selected schema

<invoice xmlns="urn:example:invoice">
  <total>forty-two</total>
  <invoice-number>INV-42</invoice-number>
</invoice>

An XSD may require invoice-number before total and require total to be decimal. Another schema could allow this exact shape. Include the schema identity when reporting the failure.

3. Schema-valid but rejected by the application

<payment xmlns="urn:example:payments">
  <account>closed-account-17</account>
  <amount currency="USD">42.00</amount>
</payment>

The schema can confirm strings, decimals, currency syntax, element order, and occurrence counts. It cannot know the current account state, the actor's permissions, available funds, duplicate-message history, or fraud policy unless those facts are supplied to application logic.

XML validation review checklist

• Question: Are you checking XML syntax, a named grammar, application meaning, signature validity, or all of them?
• Grammar identity: Which DTD, XSD, Relax NG, or Schematron version is authoritative for this message?
• Resolution policy: Are imports and references resolved through a pinned local catalog or an uncontrolled document-supplied location?
• Parser features: Are DTDs, external general entities, external parameter entities, XInclude, and network access disabled unless explicitly required?
• Limits: Are source size, nesting, nodes, attributes, entity expansion, processing time, output, and error text bounded?
• Namespaces: Are comparisons based on expanded names rather than prefix spelling alone?
• Evidence: Did you record processor and schema versions, options, warnings, and the exact artifact validated?
• Security: Are signatures verified before trusted use, and are signed-node selection and canonicalization handled by the approved library?
• Application: Are authorization, reference resolution, totals, state, replay, and business constraints checked after structural validation?