This is useful when an updated event page looks almost identical to the approved version. Its button label may be unchanged while the destination behind it points to the wrong registration form.
Keep an unmodified baseline
Save the approved and proposed files with clear names, such as event-approved.html and event-proposed.html. Keep each version's assets if they differ. Compare the versions you intend to review, rather than two downloaded copies whose dates are unclear.
Start with the raw files. Formatting both before comparison may reduce noise, but it also changes the material under review. If you later format copies, retain the originals and use the same formatter and settings on both copies. HTML formatting explains the boundary between indentation and structural repair.
Review destinations as well as wording
Consider this invented review fixture. The approved version contains:
<a href="/register/autumn-workshop">Reserve a place</a>
The proposed version contains:
<a href="/register/spring-workshop">Reserve a place</a>
A source comparison exposes the changed href; a screenshot of the button does not. Open the intended destination in the review environment and confirm which event it describes. Matching button text alone is insufficient.
Read other changed attributes in context. An altered image src changes the asset, an altered alt changes its text alternative, and a changed disabled attribute can affect whether a control works. Check scripts and styles too if the proposed version includes changes there.
Compare files without a repository
If Git is installed, its documented --no-index form compares two files on disk:
git diff --no-index -- event-approved.html event-proposed.html
It does not require you to stage or commit either file. The command returns exit status 1 when it finds differences, which a script should distinguish from an execution failure. Git diff documentation
Handle noisy changes without hiding meaningful ones
A generator can reorder attributes or change indentation across an entire document. When that happens, review smaller regions around the heading, links, data, and changed scripts. Keep the raw comparison available while using a consistently formatted copy to navigate.
Be cautious with whitespace-ignore controls. Whitespace can affect text and preformatted content, so hiding it is a viewing aid, not proof that two pages mean the same thing. A DOM comparison has its own limits because parsing can normalize markup and scripts can change the live page.
Finish with the changed behavior
Render the proposed page beside the approved version at the same width. Read the revised content, follow changed links, and operate controls affected by script or markup changes. Chrome DevTools can help inspect the element behind a confusing visual difference.
Record the baseline filename, proposed filename, and the specific changes reviewed. For the workshop page, that record should identify the registration destination you checked. Keep the proposed file unapproved until its actual destination and behavior match the intended event.