Does the tool handle self-closing tags and void elements correctly?

The tool is a text-level diff and compares HTML as raw text characters. Self-closing tags written as and void elements written as are compared exactly as written. If one file uses and another uses , the diff will show a change on that line. To treat these as equivalent, normalise both files with the HTML Formatter using the same self-closing tag setting before diffing, so both files use the same convention throughout.

Browse tools

Free · Fast · Privacy-first

Compare HTML Files Online

Track changes in HTML templates, components, or pages by comparing two versions side by side.

⚡

Highlights tag, attribute, and content changes

🔒

Works with full pages and HTML snippets

✨

Format HTML first for cleaner diffs

⚡

No upload to server, files stay local

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Diff Checker to your website

Drop the Diff Checker into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/developer/diff-checker?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Diff Checker by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/developer/diff-checker?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Diff Checker by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Getting a Clean HTML Diff Without Whitespace Noise

HTML files are sensitive to whitespace in ways that make naive text comparison noisy and difficult to interpret. Different templating engines, build tools, and code formatters apply different indentation conventions: one tool uses two-space indentation and another uses four-space, one developer's editor auto-inserts blank lines between block elements and another's removes them, and minification tools strip all indentation entirely. When you diff two versions of an HTML file processed by different tools or edited by different developers, the majority of reported differences can be whitespace changes that carry no semantic meaning. This noise makes it hard to identify genuine changes in tag structure, attribute values, or text content among dozens of false positives caused purely by formatting differences.

FixTools handles HTML comparison most effectively as a two-step process. First, paste both HTML files into the FixTools HTML Formatter and apply consistent indentation, typically two spaces, to both files using identical settings. This step normalises whitespace throughout both documents, standardises attribute quoting style, and ensures self-closing tags are formatted consistently. Second, paste both formatted outputs into the left and right panels of the Diff Checker and run the comparison. The Myers diff algorithm then operates on semantically normalised text, so every highlighted line in the output corresponds to a genuine change in tag structure, attribute value, or text content rather than a formatting artefact introduced by different tools.

When reviewing HTML diffs, pay particular attention to changed attribute values, especially on security-sensitive and functionally critical attributes such as href, src, action, and data- attributes. A changed URL in an href or src attribute can represent a significant security or functional change that is easy to overlook among many other cosmetic edits. Similarly, changes to ARIA attributes, class names that carry JavaScript behaviour, and form action targets all warrant careful review. Use the side-by-side view to see the full surrounding context for each changed attribute without losing track of which element the change belongs to.

There is an important security angle to comparing HTML in the browser rather than uploading it to a server. HTML often carries embedded inline scripts, tracking pixels, third-party iframe sources, and form action endpoints, all of which can be sensitive in a security review. Pasting HTML into a server-side diff service could expose authentication tokens embedded in URLs, private endpoints in form actions, or unreleased page content to whatever logging or analytics the service applies. The FixTools comparison runs entirely client-side in JavaScript, so the HTML you paste never leaves the tab and cannot be retained by any server. The Myers algorithm operates on the lines you provide after formatting, which makes it suitable for comparing rendered DOM output captured from browser DevTools as well as raw server-sent HTML, without any concern about leaking page content during the security audit itself.

Myers diff algorithm paper HTML Living Standard (WHATWG)

How to use this tool

💡

Paste two versions of your HTML into the comparison panels. For cleaner results, format both with the FixTools HTML Formatter before diffing to remove whitespace noise.

How It Works

Step-by-step guide to compare html files online:

1
Format your HTML files
Optional but strongly recommended: paste each HTML file into the FixTools HTML Formatter and apply consistent two-space indentation to both files using the same settings. This removes whitespace noise before you diff.
2
Open Diff Checker
Navigate to the FixTools Diff Checker tool in your browser. No account or installation is needed.
3
Paste original HTML
Paste the original or older version of your HTML into the left panel. Make sure you are pasting the complete HTML content rather than just a fragment.
4
Paste updated HTML
Paste the newer or modified version into the right panel. If you formatted both files, paste the formatted output from each.
5
Compare
Click Compare to see all changed lines highlighted. Additions appear in green, deletions in red, and modified lines show specific changed attributes or content within the line.

Real-world examples

Common situations where this approach makes a real difference:

Reviewing a CMS template update

A front-end developer receives an updated email template from a designer and needs to confirm only the approved layout changes were made. After formatting both template versions with consistent indentation, the Diff Checker reveals the expected layout changes plus an unexpected modification to the tracking pixel URL that the developer would have missed in a visual review of the rendered email. The change is caught before the template goes live, preventing broken analytics tracking on the next campaign.

Catching unexpected changes in a deployed page

After a deployment, an SEO specialist notices a ranking drop and suspects the page title or meta description was accidentally modified. Comparing the live page source against the pre-deployment source in the Diff Checker immediately identifies a missing closing tag that caused the meta description to be malformed in the deployed version, confirming the cause and giving the developer an exact line number to fix.

Comparing component library versions

A UI developer is upgrading a component library version and needs to understand exactly which HTML attributes and class names changed between the old and new library releases. Diffing the generated HTML output of a representative component before and after the upgrade reveals all changed class names, new ARIA attributes added by the library, and removed data attributes, giving the developer a complete migration checklist that takes seconds to produce rather than hours of manual comparison.

Verifying accessibility changes were applied

An accessibility auditor requests specific changes to an HTML document: adding alt attributes to images, updating ARIA roles on interactive elements, and correcting the heading hierarchy. After the developer makes the changes, the auditor pastes both the original and updated HTML into the Diff Checker to confirm every requested change was applied correctly and that no other elements were unintentionally modified during the accessibility remediation work.

Pro tips

Get better results with these expert suggestions:

Format both files with the same formatter settings

The key to a clean HTML diff is applying identical formatter settings to both files before comparing. If one file is formatted with two-space indentation and the other with four-space, the diff will show false positive changes on every indented line throughout both files. Use FixTools HTML Formatter with the same indentation and attribute settings for both files. This single preparation step can reduce the number of highlighted diff lines from hundreds to just the handful that represent real changes.

Compare the source of rendered pages using browser DevTools

To compare the HTML of a live webpage against a baseline version, open DevTools in your browser, right-click the document element in the Elements panel, and copy the outer HTML. Paste it into the Diff Checker. This captures the fully rendered DOM including any HTML injected by JavaScript after page load, giving you a more complete comparison than comparing raw server-sent source files that may not reflect the final rendered state.

Check security-sensitive attributes carefully

When reviewing any HTML diff, give extra scrutiny to changes in href, src, action, formaction, and data- attributes. These attributes control where the browser fetches resources, submits form data, and executes scripts. A changed URL in one of these attributes could represent a significant functional or security change that deserves careful manual review and approval before the modified HTML is deployed to production users.

Diff individual components rather than whole pages

Large HTML pages can produce very long diffs that are hard to navigate and review thoroughly. If you know which component or section changed, extract just that component's HTML from both versions and compare the isolated fragment. This produces a focused, short diff that is faster to review and easier to discuss with the designer or developer who made the change, without requiring reviewers to scroll through hundreds of unchanged lines to find the relevant changes.

FAQ

Frequently asked questions

Yes. Paste the full HTML source of both pages, including the DOCTYPE declaration, head section, and body, and the tool diffs the entire content. For full-page comparisons, formatting both files first with the HTML Formatter is especially important because full-page HTML sources from different tools or environments often have very inconsistent indentation that generates many false diff lines without normalisation.

Inconsistent indentation generates many false diff lines where only whitespace changed, not any actual content or structure. Formatting both files to consistent indentation before diffing means the output shows only real content and structural changes. In practice this can reduce the total number of highlighted diff lines from several hundred to fewer than ten when comparing two versions of a real-world HTML template that differ in only a few meaningful places.

Yes. You can compare any HTML content, whether it is a complete valid HTML document with DOCTYPE and html tags, an individual component fragment, a Jinja or Handlebars template partial, or even a single element with its attributes. The diff tool works on whatever HTML text you paste regardless of whether it constitutes a complete document or just a structural fragment. When comparing a formatted HTML snippet against a minified one, the diff will report almost every line as changed because the line breaks differ wholesale, not because the markup differs. Always format both inputs to the same multi-line style with identical indentation before pasting, or alternatively minify both to a single line and compare. Mixing formatted and minified versions of the same document produces a diff that is technically correct but practically unreadable, and is the single most common cause of confusing HTML diff results in real-world workflows.

Yes. When an attribute value changes within a tag, the affected line is highlighted in the diff output. The character-level highlighting within changed lines makes it easy to spot exactly which attribute value changed, even when other attributes on the same element are unchanged. This is particularly useful for catching changed class names, updated URLs, or modified ARIA attribute values. A useful preparation step for catching attribute-value changes reliably is attribute-order normalisation: some templating engines and HTML formatters reorder attributes within a tag (alphabetically or by category), which causes the diff to highlight every reordered element as a change even when the attribute values are identical. Use an HTML formatter that supports a consistent attribute-sort order on both files before pasting, so that genuinely changed values become visible against a stable attribute-ordering baseline rather than buried in reordering noise.

Yes, particularly in situations where you need to review HTML template changes without a Git repository, when sharing a diff with non-technical colleagues who do not have repository access, or when auditing changes to email templates or CMS page templates that are stored in a content management system rather than in version control. It provides an accessible, visual alternative to running git diff in a terminal.

Yes. HTML emails are frequently edited in tools that do not provide version history or change tracking. Paste two versions of an email template into the Diff Checker to see every changed element, modified inline style, updated link URL, or altered tracking pixel. Catching these changes before the email is sent prevents broken links, incorrect tracking, or unintended content changes from reaching recipients.

The tool is a text-level diff and compares HTML as raw text characters. Self-closing tags written as <br/> and void elements written as <br> are compared exactly as written. If one file uses <br> and another uses <br/>, the diff will show a change on that line. To treat these as equivalent, normalise both files with the HTML Formatter using the same self-closing tag setting before diffing, so both files use the same convention throughout.

The number one cause of a useless HTML diff is one minified file and one pretty-printed file, which makes nearly every line appear changed. Run both through the HTML Formatter with identical settings before pasting. The second most common cause is one file copied from view-source in the browser and another from an inspect-element panel, which produce different output because the inspect view reflects the live DOM after JavaScript modifications. Either always copy from view-source or always copy from the Elements panel, never mix the two for the same comparison. The third cause is attribute ordering differences, which some templating engines randomise and which appear as line-level changes even when values are identical.

Run git show commit:templates/page.html to extract any template version from any commit, and paste both extracted versions into the comparison panels after formatting them with identical HTML Formatter settings. This gives a portable, screenshot-friendly diff that you can share with designers, copywriters, or product managers who do not have repository access or who would struggle to interpret raw unified diff output in a terminal. For teams reviewing email templates, CMS partials, or React JSX-as-string output, this approach often produces a clearer review artefact than the inline diff view on a Git platform because the formatter normalises whitespace before the comparison rather than after.

Pretty-printed HTML places each opening and closing tag on its own line with indentation reflecting nesting depth. The diff highlights changes at the granularity of these individual lines, so a changed attribute value on a deeply nested element appears as a single highlighted line at the correct indentation level. A removed element appears as a contiguous red block covering the opening tag, all nested content, and the closing tag. An added element appears as the corresponding green block. The indentation in the formatted output makes it immediately clear which part of the document hierarchy each change affects without you having to count opening and closing tags manually.