What an XML validator
can—and cannot—tell you.

Start with one complete document

XML represents information through nested elements and attributes. A validator can help identify a document that a parser cannot read. That is useful when inspecting an export, a configuration file, or a message sent between systems, but the word “valid” needs context.

Here is a fictional product record to try in the SLR TECH XML validator:

<catalog>
  <item id="demo-01">
    <name>Coconut &amp; Areca Notes</name>
    <quantity unit="pieces">12</quantity>
  </item>
</catalog>

The outer catalog contains one item. The item’s identifier is an attribute, while its name and quantity are child elements. The example is deliberately small: it is easier to understand an error when the entire structure fits on a screen.

Read the first parsing error carefully

When an XML parser reports a problem, begin at the reported location and inspect the opening tags above it. An error near the end of a document may originate in a missing closing tag much earlier. Use a copy of the source and repair one issue at a time.

• Match opening and closing names. <item> closes with </item>; letter case matters.
• Keep nesting consistent. Close an inner element before closing the element that contains it.
• Quote attribute values. Write unit="pieces", not unit=pieces.
• Escape reserved characters in text. Write & to represent an ampersand and < to represent a less-than sign.
• Use one document element. Two separate top-level item elements need a common enclosing element when they form a document.

These rules are part of XML’s well-formedness requirements. The W3C XML specification describes the formal document structure and character rules.

Well-formed is different from schema-valid

Change the quantity in the example from 12 to many. The text is still readable XML, even though an inventory system might require a whole number. Similarly, omitting a required product identifier may not cause a basic XML parser to fail.

A schema describes additional requirements such as permitted elements, data types, and ordering. To check those requirements, you need the correct schema and a validator that supports it. You may also need application-level checks that a schema cannot express.

SLR TECH’s basic browser validation uses the browser’s XML parser. It checks whether the document can be parsed; it does not claim to perform XSD validation. MDN documents how DOMParser reports malformed XML.

Format with care around text and namespaces

Indentation is helpful for a record composed of separate elements. Mixed content needs more care. In <p>Buy <strong>fresh</strong> produce.</p>, the spaces around the inner element help determine the visible sentence. A formatting change can affect how an application handles that text.

Prefixes also need context. If an export uses a name such as ag:item, keep its namespace declaration with the example. Removing the declaration while copying a fragment can make a valid source document appear broken. Do not rename prefixes simply to make a text comparison look smaller.

Keep signed XML in its original form and use the signing system’s supported process. A general formatter is not a substitute for XML canonicalization. For confidential or untrusted documents, follow your organization’s approved parser and data-handling process.

Review before saving

After using the XML formatter, check attributes, text content, namespaces, and any empty elements that matter to your application. Retain the original, then test the result in the actual receiving workflow. If you need help describing an error, send a short anonymized example through our contact page.