{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }}
{{ computation.values.changed_count }} changed {{ computation.values.added_count }} added {{ computation.values.removed_count }} removed
The parser reads elements, attributes, namespaces, comments, processing instructions, CDATA, and direct text.
{{ originalStatus }}
Choose a starting policy, then keep every meaning-changing rule visible below.
Added records exist only here; removed records exist only in the original source.
{{ revisedStatus }}
The comparison updates locally after every source or policy change.
Use keyed matching for record-like XML and exact position for order-sensitive documents.
Common values include id, name, key, code, uid, sku, ref, and xml:id.
Choose the evidence level that matches the review handoff.
Normalize formatting noise unless spacing inside values is part of the contract.
Use URI/local-name matching when equivalent documents may use different namespace prefixes.
Zero is neutral. Context never changes material counts, ledgers, patch operations, or chart data.
rows
{{ line.text }}
StatusKindPathOriginalRevisedReview noteCopy
{{ statusLabel(row.status) }}{{ row.kind }}{{ row.path }}{{ row.original_value }}{{ row.revised_value }}{{ row.note }}
OperationKindSelectorOriginalRevisedPatch noteCopy
{{ row.operation }}{{ row.kind }}{{ row.selector }}{{ row.original_value }}{{ row.revised_value }}{{ row.note }}
SignalValueInterpretationCopy
{{ row.signal }}{{ row.value }}{{ row.interpretation }}
Text Diff Comparator Compare original and revised text locally through unified hunks and line alignment, with audited ignore rules and clear change counts.
Extensible Markup Language (XML) Converter Turn XML into structured JSON or record-based tables with local parsing, record-path selection, whitespace controls, and schema checks.
XPath Tester Test XPath against XML or HTML in your browser, verify namespaces and result types, and inspect matched nodes before copying runtime code.
JSON Diff Comparator Compare JSON as parsed structures with configurable array matching and ignored paths, then review exact changes through path and patch evidence.

XML changes are rarely just line changes. Reformatting can move tags across lines without altering the document tree, while a one-character edit to an attribute, namespace URI, or text node can change what an application reads. Structural comparison starts by asking which elements correspond, then checks their names, attributes, and direct text.

Well-formedness comes before comparison. An XML document needs one document element, properly nested tags, quoted attributes, and bound namespace prefixes. Validity is a separate question. A well-formed document may still violate an XML Schema, document type definition (DTD), or an application’s required fields and allowed values.

Element identity
Repeated siblings can be matched by a stable attribute such as id or sku, or strictly by their position under the parent.
Namespace identity
Prefixes are aliases. Two different prefixes can name the same vocabulary when they resolve to the same namespace URI and local name.
Text identity
Whitespace can be normalized to reduce formatting noise or preserved when spaces are part of the data.

A configuration file, product feed, invoice, schema, or SVG may need a different policy. Stable keyed records benefit from identity matching, ordered instructions may need positional matching, and signed or canonicalized XML needs checks beyond a human-readable diff. Choosing the wrong policy can create false changes or hide meaningful ones.

A zero-change result means that the compared element, attribute, and direct-text records agree under the selected rules. It does not prove schema validity, canonical equivalence, signature preservation, or equality of comments and processing instructions.

How to Use This Tool:

Set the matching policy to the XML’s real identity rules before reading the change count.

  1. Paste, drop, or load the Original XML and Revised XML. Fix a well-formedness error before continuing.
  2. Choose a Review profile, then confirm Node matching. For keyed siblings, list identity attributes in priority order and use names that are unique among like-named siblings.
  3. Select the Whitespace policy, Namespace names policy, and Diff scope. Preserve exact whitespace or qualified prefixes only when those spellings carry meaning for the review.
  4. Compare the material count with the visible ledger. If the count and current view differ, widen Diff scope; if reorder noise appears, revisit the matching policy.

Interpreting Results:

Material changes counts changed, added, and removed records across the complete parsed comparison. Visible ledger rows reflects the selected scope, so a text-only view can show fewer rows without changing the material total.

  • A changed element, attribute, or text value means matched records disagree.
  • An added or removed row means a record exists on only one side under the active matching rules.
  • A notice about exact position or preserved whitespace warns that reordering or formatting may be inflating the diff.
  • Counts of comments and processing instructions are audit context; their content is not compared as value rows.

Patch operations and the change script are review aids. Their selectors are readable paths, not guaranteed executable XPath updates for an arbitrary XML engine.

Technical Details:

The comparison builds a compact structural record set rather than canonicalizing raw XML text. Each document is parsed into one rooted tree. Elements, attributes, and non-empty direct text or CDATA become comparison records; namespace declarations join the attribute records only under qualified-name comparison. Comments and processing instructions are counted separately.

Transformation Core:

StageMechanismEffect
ParseRequire one document element, nested start/end tags, quoted unique attributes, recognized character references, and bound prefixes.Malformed input stops before a diff is produced.
Resolve namesAssociate each qualified name with its prefix, local name, and namespace URI.Namespace-aware comparison can ignore harmless prefix aliases.
Build pathsUse a unique configured identity attribute when available; otherwise number like-named siblings from 1.Stable keys can make pure reordering disappear.
FlattenEmit records for elements, ordinary attributes, and direct text or CDATA.Nested structure becomes deterministic path-value evidence.
Compare and filterLabel every unioned record key, then apply the selected view scope.The full material count remains separate from visible rows.

Rule Core:

PolicyExact ruleInterpretation boundary
Keyed siblingsTry configured attribute names in order; use the first nonblank value that is unique among comparable siblings.A missing or duplicated value falls back to sibling position.
Path positionMatch like-named siblings by 1-based position.Reordering can appear as several value replacements.
Normalize whitespaceCollapse every whitespace run to one space and trim the ends in text and attribute values.Meaningful repeated or edge spaces can disappear.
Preserve whitespaceCompare normalized line endings with all remaining spacing intact.Pretty-printing can become a material text change.
URI and local nameCompare names as namespace URI plus local name; namespace declaration attributes are excluded.Different prefixes can still match.
Qualified namesCompare the literal qualified name, including the prefix, and retain namespace declarations as attribute records.Prefix-only or declaration edits become visible.

Changes shows only changed, added, and removed rows. Full tree also shows unchanged rows. Content only excludes element-name records, while Text only keeps changed direct-text records and omits attribute and element rows.

Formula Core:

The material total is independent of the selected display scope. Unchanged rows never contribute to it.

C=Nchanged+Nadded+Nremoved

A namespace example shows why the name policy matters. <fin:status> and <f:status> match under URI/local-name comparison when both prefixes resolve to the same URI. They differ under qualified-name comparison because the prefix text is part of the key.

The parser recognizes the five predefined XML entities plus decimal and hexadecimal character references. A DOCTYPE is skipped as declaration text; external entities and document-defined general entities are not resolved. Comments and processing instructions, including an XML declaration, are counted but not compared.

Each source is limited to 200,000 characters and each flattened document to 1,000 records. For repeatable evidence, keep node matching, identity attributes, whitespace, namespace, and diff scope unchanged between runs.

Limitations and Privacy Notes:

The comparison and file reading run in the browser; the compare action does not upload pasted or loaded XML. Selected files are limited to 200,000 bytes, and pasted or loaded text is limited to 200,000 characters.

  • No XML Schema, DTD, Schematron, or application-specific validation is performed.
  • No Canonical XML or digital-signature verification is performed.
  • Comments, processing-instruction content, DTD defaults, and external entity expansions are outside the value comparison.
  • Clipboard data, screenshots, downloaded evidence, and shared page addresses can still expose confidential XML.

References: