Compare XML by content, not formatting
XML files from different tools rarely look alike: one puts every attribute on a new line, another writes the whole document on one line, a third indents with tabs. A plain text diff drowns the real changes in that noise. This XML diff checks that both documents are well-formed and re-indents them the same way, with two spaces per level (the Normalize XML option, on by default). The two versions are then compared line by line, so the highlighted lines reflect content changes instead of layout.
Example
<book id="bk101" lang="en"><author>Gambardella, Matthew</author><price>44.95</price></book>compared with
<book id="bk101" lang="en">
<author>Gambardella, Matthew</author>
<price>39.95</price>
</book>reports a single difference, the <price> value (the summary reads 1 change +1 −1), because the one-line layout of the first document is normalized away.
Options explained
- Normalize XML (on by default) – re-indents both sides with two spaces per level, so a document written on one line lines up with an indented one. Files you open and the sample are re-indented automatically; after pasting or typing, untick and re-tick the box to re-indent both sides.
- Ignore whitespace – spaces and tabs at the start and end of a line, and runs of them inside a line, no longer count as changes.
- Ignore case – compare text case-insensitively.
- View – Side by side or Unified, and Collapse unchanged to fold long unchanged stretches and keep three lines around each change.
Attribute order and <!-- … --> comments are compared exactly as written; there is no option to sort attributes or to skip comments.
Worked example: generated comments
Build tools often stamp files with a comment that changes on every run, which hides the real change in a diff. Compare these two pom.xml fragments:
<!-- Generated 2026-09-01 10:14 -->
<dependency><groupId>org.example</groupId><artifactId>parser</artifactId><version>1.4.0</version></dependency>
<!-- Generated 2026-09-02 08:31 -->
<dependency>
<groupId>org.example</groupId>
<artifactId>parser</artifactId>
<version>1.4.1</version>
</dependency>After normalization the comparison shows two changed lines, the timestamp comment and the version (2 changes +2 −2). Comments are always compared, so delete the generated comment line on both sides, which you can do directly in the editors. Only the version bump from 1.4.0 to 1.4.1 remains (1 change +1 −1), which is the change a reviewer actually needs to see. Once both sides are normalized, the different indentation of the two fragments does not appear as a difference at all.
Validation first
If either document is not well-formed (an unclosed tag, a stray &, mismatched quotes), the header of that side shows Invalid XML with the line number and the status bar gives the parser message. That side is left as typed instead of being re-indented. Fix it, or check the file in the XML validator, and compare again.
Where an XML diff helps
- Configuration files – Maven
pom.xml, .NET.csprojandweb.config, Android manifests and Spring contexts. - API payloads – SOAP requests and responses, or XML exports from ERP and e-commerce systems.
- Feeds – RSS or sitemap files before and after a change.
- Documents – SVG graphics or other XML-based formats edited by different tools.
Tip: compare canonical output
If you control both systems that produce the XML, the most reliable comparisons come from canonical output: consistent encoding, sorted attributes and no generated timestamps. Normalizing here removes the layout differences without changing either system; attribute order and comments have to match at the source.
Limits
The comparison is line based after normalization, so moving an element to a different position shows up as a removal and an addition, and namespace prefixes are compared literally. Attributes are compared in the order they are written, so <a x="1" y="2"> and <a y="2" x="1"> count as different lines. Whitespace inside text content is significant in XML and is compared as is unless you tick Ignore whitespace. For JSON data, use the JSON diff; to format a single document for reading, use the XML formatter.
Both documents are processed in your browser and are not uploaded.