XML Diff Online
Compare XML files side by side and highlight every structural change.
When an XML diff is the right tool
XML still carries a lot of production state: SOAP and other API envelopes, Maven POM files, Spring bean definitions, Android layouts, SVG drawings, RSS and Atom feeds, and exports from tools that never switched to JSON. Two of those documents can look almost the same in an editor and still disagree in a way that breaks a parser. An XML diff is for that moment. You put the previous version on the left, the new version on the right, and read every added, removed, or replaced line instead of scanning both files by eye.
This page is aimed at that comparison, not at general-purpose editing. If you only need to tidy indentation on a single file, use the XML Formatter. If you need to know whether a document conforms to a schema, use a validator. If you need to know what changed between last week's feed and today's, you want a side-by-side view with line numbers and a chance to hide formatting noise first.
Use cases
Checking an API or SOAP envelope before a client ships
A backend change often arrives as one XML fixture that mixes several decisions: a new child element, a renamed attribute, a status code tucked inside a SOAP body. Pasting the old and new envelopes makes each decision visible as its own marked line, so QA can ask “did we mean to add this element?” instead of rereading a 200-line blob.
Reviewing build or framework configuration
Maven POMs, Spring XML, and similar files are easy to misread in a pull request because most of the file did not change. A one-value edit — a dependency version, a bean class, a profile flag — is easier to trust when it is the only green or red line on the page.
Comparing SVG, layouts, or a feed
SVG path data, Android layout XML, and RSS items are all tag-based documents. A new item in a feed, or a single attribute on a layout view, should read as an addition or a small replacement, not as a wall of re-indented markup. Turn Pretty-Print on before you compare if one side came out of a minifier or an IDE auto-format.
How the comparison works
This tool compares the two documents as text, line by line, using the same style of alignment you see in a typical unified or split diff. Identical lines stay across from each other. A line that exists only on the left is marked as removed. A line that exists only on the right is marked as added.
Pretty-Print, which is on by default, is a best-effort indent step rather than a full XML parser. It splits the input into tags and text nodes, then rewrites each on its own line with consistent two-space indentation. The point is to stop a minified document and a pretty-printed copy of the same tree from lighting up as hundreds of fake changes. If the indent step cannot run, the tool falls back to the text you pasted.
It does not build a tree, match elements by id, sort attributes, or rewrite namespace prefixes. That honesty matters: the result is easy to read, and it will not pretend that two namespace spellings are the same when they are only equivalent to a parser.
<book id="42">
<title>River Atlas</title>
<price currency="USD">24</price>
</book>
<book id="42">
<title>River Atlas</title>
<price currency="USD">29</price>
<stock>12</stock>
</book>After Pretty-Print, the title line stays unchanged. The price line appears as a removal of 24 and an addition of 29. The new stock element appears only on the right. That is the distinction you want when writing a changelog: an edited price is not the same kind of change as a new child.
<widget enabled="true" name="queue"/>
<widget name="queue" enabled="true"/>These two widgets have the same attributes. In XML they are equivalent, but because each opening tag is a single line, a line diff reports a change. If that is the only difference you see, the documents are probably the same for a parser. Reorder the attributes if you want the lines to match, or ignore that one line.
What this tool does not do
It does not validate a DTD or XSD, canonicalize the XML Information Set, or send your document to a server. It will not resolve entities beyond what you pasted, and it will not treat a default namespace and a prefixed namespace as equal. Malformed input can still be compared as raw text; the pretty-printer may then leave it alone. Binary files and Word or Excel packages that only happen to contain XML internally belong in a different workflow: unzip them first, then compare the parts you care about.
How to use XML Diff
- Paste the older or expected document into the original pane.
- Paste the newer document into the modified pane.
- Leave Pretty-Print enabled unless you specifically want to see indentation and wrapping differences.
- Choose Compare. Switch between split and unified views, and copy the result if you need to keep a record. Use Swap if the sides are reversed, and Clear when you are finished.
Frequently asked questions
What does the Pretty-Print option actually change?
It re-indents the two documents with a simple tag tokenizer before they are compared, so a minified file and a neatly indented copy of the same XML usually line up. It does not parse a formal XML tree, sort attributes, or rewrite namespace prefixes.
If two tags have the same attributes in a different order, will they look identical?
Not in this tool. Attribute order is not significant in XML, but the comparison is line-based. If the opening tag sits on one line and the attributes swap places, that line is marked as changed. Reorder the attributes to match, or treat that one-line difference as formatting rather than a real edit.
Can I compare HTML or SVG here?
You can paste them, because both are tag-based markup. SVG that is well-formed XML pretty-prints cleanly. HTML is often not well-formed XML (unclosed tags, attribute shortcuts), so pretty-print may be imperfect. For HTML-specific documents, the HTML Diff page is usually a better starting point.
Does XML Diff validate against an XSD or DTD?
No. This page tells you how two documents differ, not whether either document is valid. Use a schema validator or a tool such as xmllint when you need validity, then come back here to inspect a change.
Is my XML sent to a server?
No. Comparison runs in your browser. Closing the tab discards what you pasted. Do not paste documents that contain secrets if you would not be comfortable with them sitting in memory on this device.
Is there a file size limit?
There is no server-imposed limit, because nothing is uploaded. A few thousand lines is comfortable. Multi-megabyte exports can make the page feel slow; in that case, compare a smaller fixture or use a local tool.
How is this different from a plain text diff?
The visual result is a line diff, like the text tool on the homepage. This page exists to explain XML-specific pitfalls (pretty-print, attribute order, namespaces) and to offer a one-click indent step before comparing. It does not yet compare elements by identity independently of line breaks.
Does it understand XML namespaces?
Prefixes and declarations are compared as literal text. A document that uses a default namespace and another that uses a prefix for the same URI will not be treated as equal, even if a namespace-aware parser would consider them equivalent.
Related tools and guides
References
- W3C XML 1.0. Defines elements, attributes, and document structure. Attributes are unordered in the specification, which is why a change of attribute order alone should not be treated as a semantic change.
- xmllint (libxml2) is a good local companion for formatting, validity checks, and XPath queries. Validating a document first, then pasting it here to inspect a change, avoids a lot of confusion.
- Libraries such as XMLUnit compare by element and attribute rather than by line. Use them when two documents differ only in wrapping or attribute order but share the same tree.