Checking XML: well-formed does not mean business-valid
A system may reject XML because a tag is unclosed or because a correctly written value is unsuitable for the request. Diagnosis starts by separating those two kinds of failure.
Structure is the first layer of correctness
XML requires one root element and properly nested elements. Closing a tag with another name or using separate roots breaks that structure even when a person can infer the intended meaning.
Permitted fields and values belong to another layer. A well-formed document can still contain a negative amount or a code rejected by the receiving system.
References: W3C — XML 1.0 well-formedness and validity
Useful formatting does not rewrite the content
Whitespace between elements can aid reading, but spaces in text mixed with elements may belong to the sentence. Removing them or adding arbitrary line breaks can change the readable result.
ToolRoof preserves mixed text and handles the scope of xml:space. Do not treat reformatting as byte-preserving or as a way to preserve a digital signature; keep the original when comparing.
Know which validation you actually received
This tool checks XML 1.0 well-formedness and formats it. It does not validate XSD or DTD, or retrieve external entities. DOCTYPE and ENTITY declarations are rejected rather than treated as supported.
Passing this check does not establish acceptance of a tax, financial or other official submission. After fixing structure, use the recipient’s actual schema and rules in an appropriate environment without unnecessarily sharing sensitive data.
Example: a negative amount in well-formed XML
<order><amount>-5</amount></order> is well-formed and contains two elements. It does not tell us whether -5 is allowed; that requires a rule beyond the XML structure check.
<order><amount>5</order> is structurally invalid because amount was not closed before order. In <p>Read <b>this</b> now.</p>, the spaces also matter: formatting must not join the words together.