Screenshots & visual diff

Three dedicated viewports are captured with Playwright Chromium: desktop 1280×800 (Mac Chrome UA), tablet 820×1180 (iPad Safari UA, mobile profile), mobile 375×812 (iPhone Safari UA, mobile profile). Each is diffed separately — you immediately see when a bug only affects mobile.

Screenshots across 50+ real viewports: iPhone 17 Pro Max / 17 Pro / 16 Pro Max / 16 Pro / 16 Plus / 16 / 16e / 15-series / SE, Galaxy S25 Ultra / S25+ / S25 / S24-series, Pixel 10 Pro XL / 10 / 9-series / 8-series, OnePlus 13, Xiaomi 15, Galaxy Z Fold 6 (unfolded+cover), Z Flip 6, Pixel 9 Pro Fold, iPad Pro M4 13/11, iPad Air M3, iPad Mini A17, Galaxy Tab S10 Ultra/+, MacBook Air 13/Pro 14/16, FHD/QHD/4K/5K, ultrawide 21:9/32:9 — plus landscape variants for every key device and custom pixel sizes. Smart picker with search, category chips (New 2025/26, Foldables, Landscape, Legacy) and visual mini-mockup per device. Parallel render (4 Chromium contexts concurrently by default, shared URL fetch/cache → noticeably faster). Every device is captured in BOTH light and dark theme. Plan gates: Free 4 devices × 1 scan/day, Starter 7 × 30/month, Business 15 × 200/month, Agency unlimited. Custom pixel sizes are allowed up to 4000×4000 px, up to 20 custom viewports per scan.

If you add a cookie banner or change a section height, all content below shifts — without correction, the diff would flag every pixel below as “changed”. XICTRAQ scans vertical shifts automatically (coarse up to ±80 px, at most 5 % of the image height, then ±3 px fine) and aligns the images before diffing. Result: you only see real changes, not cosmetic reflows.

Some sites display random content per reload (rotating banners, dynamic reviews, A/B tests). If the y-shift-corrected diff against the baseline exceeds 3.5 %, XICTRAQ runs a second screenshot after 15 seconds and compares the two consecutive captures with each other. If the two runs already differ by more than 2 % and this noise largely explains the difference to the baseline (less than 3 percentage points left), the page renders inconsistently on its own — the finding is marked “flap” (flap_detected) and suppressed: no changelog entry, no alert. For resource reasons this 15-second rescan runs only for the first two changed pages per check cycle.

Long pages are scrolled fully and captured as full-height screenshots — a footer change at the bottom of a 4000-px page is detected just as reliably as a hero change.

Instead of leaving you with raw pixel differences, XICTRAQ states the percentage of changed pixels and whether the page height shifted — rule-based, no AI hallucination risk. Every changelog entry gets a severity from fixed thresholds: > 3.5 % info, > 10 % warning, > 20 % critical. Only from 20 % does a dedicated alert additionally fire. When XICTRAQ detects a layout/length artifact (height delta > 25 % or a vertical shift of 55 px or more), the severity is deliberately capped to info and no alert is fired — because then the captures are not directly comparable and the pixel diff is not a reliable content signal.

So the very same page stays pixel-stable across days and not every reflow counts as a “change”, XICTRAQ stabilises each capture: cookie/consent banners are auto-clicked or hidden, CSS/JS animations and transitions frozen to 0 s (no half-faded hero slider), horizontal overflow clamped to the exact viewport width and accidentally opened off-canvas menus closed via Escape. Tracker and analytics requests (including our own) are blocked, so the screenshot itself never skews visitor statistics.

Each viewport (desktop, tablet, mobile) is checked against its own baseline, and the baseline is bound to the full URL (host + path) — so multiple monitored subpages of the same domain do not overwrite each other. Via the monitored content pages, XICTRAQ additionally captures screenshots of selected subpages in all three viewports. When monitoring runs on a remote node, the before/after/diff image travels base64-encoded (capped at 4 MB per image) to the API, so the comparison can be archived even without a shared filesystem.

The percentage of changed pixels versus the baseline (visual_pct), already y-shift-corrected and flap-filtered. A large-area visual overwrite — e.g. a fully replaced home page — triggers here immediately, even when the HTML code was cleverly obfuscated.

The HTML is normalised before hashing (whitespace, dynamic tokens, CSRF fields and cache busters are stripped) so legitimate fluctuation does not cause false alarms. If the hash still changes (html_changed), the structure or content was altered — even when the rendered image looks almost identical.

A structural fingerprint of the DOM counts, among other things, every external script and iframe host. When new third-party hosts appear that are not in the learned baseline (new_script_hosts, new_iframe_hosts), this is a strong indicator of an injected skimming script or a foreign iframe — the classic Magecart signature.

The three layers are not evaluated in isolation but merged into a single defacement score from 0 to 100. Every event lists the contributing layers (layer: pixel / html_hash / dom) with status and detail, so you see at a glance which signals fired together. Only the interplay of several layers produces a high score — a single harmless signal stays low.

After activation, the first 3 screenshot runs establish the baseline (learning: true, learned_runs counts up). During this learning phase NO alert is raised on purpose — XICTRAQ first learns how your page normally looks, which external script hosts are legitimate (baseline_script_hosts) and how the HTML hash fluctuates. After that the baseline is set (baseline_learned_at) and monitoring kicks in.

Defacement detection is enabled per website via a watch toggle (watch: true). It is off by default — you switch it on deliberately for the pages where a takeover would hurt most, e.g. shop home page, checkout or login. Enabling it automatically starts the learning phase.

When the score reaches 60 or more, XICTRAQ creates an event (status: open) and fires an alert with severity “critical” via your configured channels (email, Slack, Discord, Teams, Telegram, webhook, browser push). The event carries the score, contributing layers, visual_pct, html_changed and the lists of new script/iframe hosts — everything you need for a quick assessment.

If the score drops below 30 again in a later run, an open event is automatically set to “resolved” (resolved_at). This way short-lived incidents — e.g. an accidentally published maintenance page that was quickly rolled back — close on their own without manual clean-up. You can also mark an event as resolved manually at any time.

The baseline deliberately does NOT change on its own — a new score never overwrites it automatically, so an attacker cannot “train in” the detection through gradual changes. After a planned relaunch or redesign you reset the baseline once via “re-learn baseline”; 3 learning runs then start again and define the new target state.