HTML Snapshots: Never Wonder What Changed on Your Website Again
HTML snapshots are stored copies of your page's normalized HTML, saved automatically when content changes are detected. They give you a point-in-time record of what your site looked like, letting you pinpoint exactly what changed, when, and by how much.
Quick answers
What is an HTML snapshot?
An HTML snapshot is a saved copy of your web page's normalized HTML at the moment a content change was detected. It's stored in your dashboard so you can review it later and compare it against previous or current versions.
How many snapshots are stored per website?
JF Website Monitor keeps the 10 most recent snapshots per website. When an 11th snapshot would be stored, the oldest one is automatically deleted.
What does "normalized HTML" mean?
Normalization strips elements that change on every page load regardless of content — things like session tokens, timestamps embedded in script tags, and certain inline styles. This prevents false positives from technical page noise while preserving meaningful content changes.
Are snapshots only stored on content changes?
Snapshots are stored whenever the HTML hash differs from the previous check, even if the difference falls below your alert threshold. This means you have a record of all HTML variations, not just the ones that triggered alerts.
The Problem With "Content Changed" Alerts Alone
A content change alert tells you that something on your page is different from the last check. Without more information, that's only marginally useful. Did the copyright year in the footer change? Did someone accidentally publish a draft article? Did the checkout button disappear? Did a third-party script get injected?
The alert gets you to your laptop. The snapshot tells you what you're dealing with before you even open your browser.
How JF Monitor Creates Snapshots
On every check, JF Website Monitor fetches your page HTML and runs it through a normalization process:
1. The raw HTML is parsed and inline noise (session tokens, random IDs, timestamps in attributes) is stripped 2. The normalized HTML is hashed with SHA-256 3. If the hash differs from the previous check, the normalized HTML is stored as a new snapshot 4. If the percentage of change exceeds your alert threshold, a change detection alert is fired
The key detail: snapshots are created on ANY hash difference, not just changes that exceed your threshold. This means you have a complete record of all HTML variations over the 10 most recent distinct states.
Reading Snapshots in the Dashboard
From your website detail page, the Snapshots tab shows your stored snapshots in reverse chronological order — newest first. Each entry shows the timestamp, the change percentage compared to the previous snapshot, and whether it triggered an alert.
Click any snapshot to view the full normalized HTML. This is the actual content of your page at that point in time — headers, body copy, navigation links, form fields, and so on. You can compare it mentally (or copy-paste into a diff tool) against another snapshot to identify the specific lines that changed.
What Snapshots Help You Catch
In practice, snapshots are most valuable for these scenarios:
**Unexpected content changes:** A CMS update, a plugin conflict, or a bad deployment puts the wrong content on a page. The snapshot shows the exact HTML state at the time of the incident.
**Third-party script injections:** Malicious or accidental script injection shows up in the HTML. A snapshot taken at the time of detection preserves the injected code for forensic review.
**Layout breakage:** If CSS is stripped or JS fails to load, the normalized HTML may still reflect the issue through missing elements or changed class names.
**Gradual drift detection:** By reviewing the last 10 snapshots, you can see how a page has evolved over time — useful for understanding when a problem started rather than just that it happened.
Limitations to Keep in Mind
Snapshots capture normalized HTML — the document structure and text content — but not visual rendering. If a CSS file changes in a way that breaks your layout without changing the HTML, the snapshot won't capture that. Similarly, JavaScript-rendered content (single-page apps that write content into the DOM after load) won't be fully captured since we fetch the raw server-returned HTML.
For JavaScript-heavy sites, the HTML snapshot still captures the initial server render and any inline data, which often includes the content you care most about. But for full visual regression testing of JS-rendered applications, a headless browser tool is a better complement.