XML Diff

About the XML diff tool

Paste two XML documents and this tool shows exactly what separates them — as a familiar line-by-line diff, as a structural tree comparison, or both. Everything is parsed and compared in your browser: build configs, SOAP envelopes, sitemaps, and application settings never leave this tab.

How to use it

Load the original document on the left and the changed one on the right — paste directly or start from the Sample to see the tool in action. The Paste button copies the left document into the right panel for quick hand-edits before comparing. Hit Compare and the output renders immediately; use Expand all / Collapse all to manage large trees and Search to jump to a specific element or value.

Two views, two purposes

The defaultDiff view is a line-level diff of both documents pretty-printed the same way, so you can see exactly which lines changed. Switch to Tree for a structural comparison that walks the element tree instead — attributes, text, and child elements are marked added, removed, or changed, with a dashed marker on any collapsed branch that contains a change. The two views are complementary. A re-indentation-only change shows up in the line view but not the tree view, while a change that touches an attribute value is called out precisely by the tree view. Hover any diff line to copy it, or use the per-node copy menu in the tree view.

What counts as a change

Because both documents are normalized through the same pretty-printer before the line diff, pure formatting noise — different indentation styles, CRLF versus LF endings, self-closing tags written either way — never produces phantom differences. In the tree view, element and attribute names keep their namespace prefixes, so namespaced documents compare correctly, and repeated sibling tags are grouped by name rather than position.

The change counters

Above the output, three counters summarize the comparison: how many nodes wereadded (green), how manyremoved (red), and how manychanged (amber). They're the fastest way to size up a diff before reading it — zero changed but several removed tells a very different story from three of each. The same color coding drives the in-tree highlights, so once you know what you're looking for, you can navigate straight to it.

Common pitfalls it avoids

Attribute order

XML defines no meaningful attribute order; the tree view treats reordered attributes as equal instead of flagging every line.

Sibling ordering

The line view is order-sensitive (useful when sequence matters, like configuration sections), but the tree view groups siblings by tag name so reordering won't mask real changes.

Whitespace-only text nodes

Indentation between elements is normalized away, so re-formatting a file doesn't register as content churn.

Everyday scenarios

Compare a project's pom.xml before and after a dependency upgrade, review what a release changed in a Spring or .NET config, audit two environments' web.config files side by side, check a vendor's updated WSDL against the old one, or verify that a generated sitemap only gained URLs you expect. Anywhere two XML files should differ in known ways, the counters and highlights turn a manual read-through into a thirty-second check.

Tips for reliable comparisons

Run each side through the XML formatterfirst if the sources are machine-generated minified files — although this tool normalizes formatting itself, starting from readable documents makes any surprise obvious faster. Watch the XML declaration: differing encoding or standalone declarations show up in the line view, which is usually what you want when merging config across environments. For generated files where only a few elements should change, read the tree view's dashed markers first — they lead you straight to the branches containing changes without walking the whole hierarchy.

Related: pretty-print and validate either side with the XML formatter, or compare JSON configuration with the JSON diff tool.