This tool vs. eyeballing two page loads side by side
Ten words added to a page of hundreds reads naturally either way. A glance cannot tell that anything moved; a byte-for-byte diff cannot miss it.
What eyeballing two page loads tells you
Opening a vendor's privacy or subprocessor page again and comparing it to what you remember, or to a saved copy, is the cheapest, most common way anyone re-reviews a vendor page, and it is not wrong to do it: a whole new section, a moved heading, or an obviously rewritten paragraph is exactly the kind of change a person scanning for something different will catch.
What a glance is unreliable for is the change that matters most in practice: a clause added or removed inside a paragraph that still reads naturally, in a page of hundreds of words where nothing about the page's shape signals that anything moved. Nobody scanning a long policy page is running a word-by-word count against last month's version in their head.
A real pair, from this tool's own shipped example
This is not a hypothetical. It is the before/after snapshot pair shipped with this tool's own examples, reproduced exactly:
before.json (captured 2026-08-23T09:00:00Z): "We process account data to provide the service." after.json (captured 2026-08-24T09:00:00Z): "We process account and usage data to provide the service."
A day apart, the same URL, the same fetch status. On a real vendor page this sentence would sit inside a much longer document, and "account data" quietly becoming "account and usage data" changes what the vendor says it collects without changing the shape of the page at all -- no new heading, no bold notice, nothing to catch the eye of someone comparing the two by scrolling and scanning.
Running this tool against the same pair instead:
{
"status": "changed",
"changes": [
{ "kind": "content_changed", "before_length": 47, "after_length": 57 }
],
"review_required": true,
"evidence_boundary": "Reports observations; the customer decides
contractual or security significance."
}
The tool does not know or care whether ten extra characters matter --
that judgment is explicitly left to you, per its own
evidence_boundary. What it does not do is fail to notice
the ten characters, because it never reads for meaning; it compares
every character in before.text against every character in
after.text.
Side by side
| Eyeballing two page loads | This tool |
|---|---|
| Catches a rewritten section or a new heading -- anything that changes the page's shape. | Catches every difference between the two texts, whether or not the page's shape changed at all. |
| A clause added inside a paragraph that still reads naturally is easy to miss on a scan. | Reports content_changed for a one-character difference exactly as reliably as for a rewritten page. |
| A failed page load that quietly shows a cached or stale copy can look identical to "no change". | Checks fetch_status on both captures first; either one not ok reports inconclusive, never a false "unchanged". |
| Leaves no record beyond a person's memory of having looked. | Produces a dated report -- URLs, capture timestamps, fetch status, and the verdict -- exportable as Markdown or JSON. |
| Free, and needs no tool beyond a browser tab. | Also free, local, and needs only the two snapshots you already have. |
Using both together
Nothing here argues for skipping a read of the vendor's page -- judging whether a change is friendlier or more permissive, or reading a whole new section for what it actually promises, is exactly the kind of call this tool deliberately leaves to you. The change is running the diff first, so the question stops being "did I notice anything different" and starts being "here is exactly what changed; does it matter":
Open the Vendor Change Evidence tool to diff your own snapshots, or read how do I track when a vendor changes its subprocessors or privacy policy.
Common questions
Isn't glancing at a vendor's page again good enough?
It catches a rewritten page or an obviously new section, which is real and worth doing. It is unreliable for the change that actually matters most: a few words added or removed inside a page of hundreds, in a paragraph you are not specifically looking at, worded so it reads naturally either way. A privacy page that grows from 'We process account data to provide the service' to 'We process account and usage data to provide the service' looks unchanged to someone skimming for a new heading or a bold warning, because nothing about the page's shape signals that ten words moved.
What does eyeballing two page loads actually miss, concretely?
On this tool's own shipped example, a vendor's privacy snapshot goes from 47 characters to 57 -- 'We process account data to provide the service.' becomes 'We process account and usage data to provide the service.' -- between two captures a day apart. A person opening the page twice and comparing them by eye, especially on a long real policy page rather than this one-sentence example, has to notice one clause changed inside surrounding text that reads naturally either way. Running this tool against the two snapshots reports status changed, review_required true, with the before and after lengths right there -- it does not need to notice, because it compares every character.
Can eyeballing a page ever tell you something this tool can't?
Yes -- a human reading the page can judge whether a change matters, whether new wording is friendlier or more permissive, and whether a whole new section changes what the vendor is promising. This tool deliberately does not make that judgment; its own evidence_boundary says it reports observations and the customer decides contractual or security significance. What it replaces is not judgment but noticing -- the step where a change has to be seen before anyone can judge it.
What happens when the page fails to load instead of actually being unchanged?
A person who tries to reload a vendor's page and gets a timeout, a login wall, or a CDN error page usually either notices and tries again, or -- on a routine check done quickly -- assumes the earlier capture is still good and moves on, which silently reports 'no change' when the truth is 'not checked.' This tool's compare() function checks fetch_status on both snapshots first: if either one is not ok, the result is inconclusive, not unchanged, so a failed capture can never be mistaken for a stable page.
Does this tool fetch the vendor's page for me?
No. It compares two snapshots -- url, captured_at, fetch_status, and text -- that you already have, however you captured them: a saved page, a scheduled fetch, or a copy-paste. It runs entirely in your browser and sends nothing anywhere.