XML Diff Checker

Comparing markup, and the normalization that makes it readable

XML diffing has a reputation for being noisy, and the reputation is deserved when you compare raw documents straight out of two systems. The same logical document can differ in indentation, in attribute order, in whether empty elements are written `<tag/>` or `<tag></tag>`, in namespace prefixes, in the presence of an XML declaration, and in line endings — none of which change what a parser sees, all of which change what a text comparison reports.

The fix is normalization before comparison, and for XML the single highest-value step is formatting both sides to the same indentation. A minified document on one side and an indented one on the other produces a diff in which literally every line differs; the XML Formatter applied to both turns it into a diff of the handful of elements that actually changed. It also validates as it goes, so a document that will not format is a document with a structural problem you would rather find before you start comparing.

With both sides normalized, the highlighting earns its keep. Element names, attribute names, attribute values and text content are coloured separately, so `<price currency="USD">329.99</price>` becoming `<price currency="EUR">329.99</price>` reads instantly as an attribute change rather than as an anonymous altered line. The comparison itself is the same one the plain Text Diff runs: matching lines aligned, insertions marked on the right, deletions on the left, and the changed characters highlighted inside modified lines. Both panes remain editable.

Where XML comparison earns its keep

Build configuration is the perennial one. Two Maven POMs where one project resolves a dependency and the other does not; a `pom.xml` before and after a dependency upgrade, where the question is which transitive versions moved; two `.csproj` or `web.config` files across environments. These files are long, deeply nested and edited by tooling as often as by people, which is exactly the profile that defeats reading them side by side.

Integration debugging is the second. A SOAP request that the partner accepted and one they rejected; a WSDL from the vendor against the one your client was generated from; a SAML assertion that authenticated against one that did not. In each case the documents are 95% identical and the difference is a single element, an attribute value, or a namespace declaration. Decode first if the payload arrived Base64-encoded with Base64 to XML, format both sides, then compare.

Feeds and exports round it out. Two versions of an RSS or Atom feed to see what a publisher changed; a generated sitemap before and after a deployment; two runs of a data export where a downstream consumer started complaining. Android layouts and other resource XML files fit the same pattern — machine-editable, human-reviewed, and much easier to review as a diff than as two documents.

One thing to be clear about: this is a textual comparison, not a semantic one. It will not tell you that two documents produce the same infoset despite different attribute ordering, and it will not match elements that moved a long way within the document. For those questions you want a real XML-aware differencing tool. For the everyday 'what changed between these two files' question — which is the question almost everyone actually has — normalized text comparison with markup highlighting is faster and easier to read.

XML differences that are noise, and ones that are not

XML gives you several ways to write the same document, and a textual diff reports all of them. Before you start reading a large XML diff, it is worth knowing which reported changes actually change what a parser sees.