Paste two HTML documents to see a side-by-side diff with syntax highlighting, byte size comparison, DOM node counts, and top tag frequency breakdown.
Paste original HTML on the left and modified HTML on the right. Added lines are highlighted green, removed lines red.
How to read and use HTML diffs effectively for code review and debugging.
Green lines with + prefix are lines added in the modified version. Red lines with - prefix are lines that existed in the original but were removed. Grey/unchanged lines provide context around changes. The line numbers on each side correspond to the original (left) and modified (right) documents independently.
Comparing CMS output before and after a theme update. Verifying that a refactor didn't change the rendered structure. A/B testing page variants to measure structural differences. Code review of HTML templates. Checking that a minifier preserved all content. Debugging unexpected rendering changes after a deployment.
Side-by-side diff shows both versions simultaneously with aligned lines — easier to read for small changes in long files. Unified diff shows a single stream with +/- prefix markers — more compact, standard format used by git diff, patch files, and code review tools. Use unified format when sharing diffs in text or email.
For the cleanest diff, format both HTML files consistently before comparing — whitespace differences create noisy diffs that obscure real changes. Most minified HTML will show one giant line change versus formatted HTML. Consider using the Format button to normalize whitespace before comparing CMS-generated HTML against hand-written HTML.
Why HTML size matters for performance and what the DOM analysis numbers mean.
Raw HTML file size affects download time — especially on mobile connections. Every extra kilobyte adds transfer time. Gzip typically compresses HTML to 20-30% of its original size, so a 100KB HTML file becomes ~25KB over the wire. However, the browser still needs to parse the full uncompressed HTML, which takes CPU time proportional to the file size. Keeping HTML lean improves Time to First Byte (TTFB) and First Contentful Paint (FCP).
Google recommends keeping the DOM below 1,500 nodes (ideal under 800). Excessive DOM size increases memory usage, extends style recalculation time, and causes layout thrashing. Each node in the DOM tree takes roughly 100-200 bytes of memory. A DOM with 5,000 nodes uses ~500KB-1MB of memory just for the tree structure. The DOM analysis panel above shows total element count, depth indicators, and tag frequency breakdown for both HTML versions.