HTML DOM Comparator

Two HTML files can look alike as text and still produce different document trees. Browsers repair missing tags, insert implied elements, decode character references, and apply special rules to tables, templates, SVG, and MathML. A source diff shows where characters changed. A Document Object Model (DOM) comparison instead reports which elements, attributes, text nodes, comments, and document-type nodes remain after parsing.

That distinction matters during template upgrades, content migrations, rendering regressions, and component reviews. Reordered attributes normally do not change an element. Reordered class tokens often preserve the same set of classes. A whitespace-only text node may be harmless around block elements and important inside preformatted content. Comparison rules therefore need to match the purpose of the review rather than hide every noisy difference by default.

HTML source

The character stream that was written, copied, or generated.

Parsed DOM

The node tree produced after HTML parsing and error recovery.

DOM path

A location such as /document/html[1]/body[1]/main[1] that identifies a node by ancestry, name, and sibling position.

A zero-change result is always conditional on the selected rules. Ignoring whitespace, text case, attributes, or a whole path makes the report quieter, but it also removes those differences from review. DOM equality does not prove equal styling, layout, accessibility, script behavior, network requests, or visual output. Those need CSS, runtime, accessibility, and screenshot checks of their own.

HTML parsing is also forgiving by design. A tree can be produced from malformed source, so parser recovery findings deserve attention even when the normalized trees match. A repaired tree may be useful for comparison without being source that should ship unchanged.

How to Use This Tool:

Decide which default normalization rules are safe for the review, and turn them off when exact DOM values or ordering matter.

1. Paste or load the earlier source in Baseline HTML and the revised source in Candidate HTML. Each side accepts a document or fragment up to 120,000 characters.
2. Choose HTML document for a complete page or HTML fragment for a component snippet. The choice changes the parser context and every reported path.
3. Run the first review with only the defaults you trust. Open Advanced to change whitespace, attribute order, class-token order, inline-style order, or text-case handling. Add ignored attributes or path prefixes only when those values are genuinely outside the review.
4. Read Review brief for counts and parser findings, then use Change ledger to inspect the exact path, baseline value, candidate value, and review note for each material difference.

Interpreting Results:

Changes counts the rows that remain after parsing and normalization. Added and removed rows identify nodes or attributes present on only one side. Changed rows cover text, comments, doctypes, attribute values, and strict attribute-order differences. Moved rows pair an unchanged subtree that disappeared from one path and appeared at another.

• Check parser recovery findings before treating a match as clean HTML.
• Review ignored attributes and paths whenever a zero-change result will support a release or migration decision.
• Treat path shifts carefully. Adding an earlier same-name sibling can change later positional paths even when the later content itself is unchanged.
• Use a rendered-page test when CSS, scripts, form state, accessibility, or layout is part of the acceptance question.

Move detection is conservative: only an unchanged subtree with the same normalized fingerprint is paired as moved. A node that moves and changes at the same time can appear as removal, addition, or separate internal changes rather than one move.

Technical Details:

HTML comparison begins with standards-oriented parsing, not string tokenization. Document mode builds a document root; fragment mode builds a fragment root. Elements, text, comments, and the doctype become bounded comparison nodes. Template contents are traversed as child content, while HTML, SVG, and MathML element names retain their namespace distinction.

Transformation Core:

Rule Core:

Each switch changes a specific equality rule. None of them changes the original text shown in the editors.

The comparison accepts at most 5,000 parsed nodes per side, 80 levels of depth, and 100 attributes on one element. It records up to 500 change rows and up to 25 parser findings per side. When a report reaches its row limit, the truncated result is a partial review rather than evidence that later nodes match.

The headline total is the number of retained change rows after move consolidation. Added, removed, changed, and moved counts partition that total; parser recovery findings are reported separately because they describe source parsing rather than a difference between the two trees.

Privacy and Limits:

The two sources are parsed and compared in the browser. Loading a local HTML or TXT file reads it into the current tab; the comparison does not require uploading the source to a document-processing service.

• HTML is treated as inert input for parsing. The comparison does not execute embedded scripts or load page resources.
• DOM equality does not compare computed CSS, layout, pixels, accessibility trees, event behavior, network activity, or browser-specific runtime state.
• Parser recovery can produce a usable tree from invalid source. Review the recovery list and validate source syntax separately before release.
• Ignored rules can conceal material differences. Keep a record of the selected policy when the report supports a formal review.

References:

• HTML Standard: Parsing HTML documents, WHATWG, Living Standard.
• parse5 standards-compliant HTML parser, parse5 project.