How your scans are handled

What leaves your browser when you scan

Submitting a scan sends the following to the scanner:

• The address: reduced to origin and path first. Before the request leaves your browser, the query string (everything after ?) and fragment (after #) are stripped. example.com/account?user=you&token=abc becomes example.com/account. The page in the box is updated so you can see exactly what will be scanned.
• Your scan options: the device profile (desktop or mobile), whether to send a Global Privacy Control signal, and which run mode: Single (one visit), or a GPC diff, Blocker, or Consent comparison (each comparison visits the page twice so the pair can be compared).
• A Cloudflare Turnstile token, used to confirm the request is not automated abuse (see Third parties below).
• A scanner access key, only on a gated deployment. If an operator requires this key, it is sent only to that scanner for admission, status, or cancellation. The page keeps it in memory while open; it is not placed in local or session storage, and a reload requires it again.

Local PageGraph imports

Opening a paired PageGraph .graphml and .meta.json file is a browser-only import. The raw artifact bytes are read in your tab and are not sent to the scanner or stored by this service. The normalized local report also omits the source-artifact digest so separately shared reports cannot be linked back to the same raw capture by that fingerprint.

Treat raw PageGraph files as sensitive before selecting or sharing them: captures can contain request headers, URLs, storage identifiers, or other page-controlled values. Site Behavior Lab emits only the privacy-reduced request evidence supported by this importer and marks cookie, storage, fingerprinting, detector, and consent families unsupported.

What the scan itself does

In Single mode the report contains one measured browser run; comparison modes contain two runs, one per compared condition. Each run records what the page did: the network requests it made, the cookies and storage it set, fingerprinting-style API calls, and an immediate screenshot of the page (never of you or your device). That screenshot is not saved in the share report. The scanned site sees traffic from the scanner’s infrastructure, not from your IP address.

A run can make additional bounded navigations. Consent verification may reload the page once after a click; the input probe may navigate to a blank page at the end so unload beacons fire; and policy analysis may open the site’s disclosed privacy-policy page through the same SSRF guard after the main request log is frozen. Reload- and policy-phase requests are excluded from the main counts. Unload beacons sent by the measured page during the input probe remain part of the recorded evidence.

When optional restart-safe execution is enabled, a scanner or coordinator failure can abandon an attempt and retry it once. The scanned site may therefore see an extra automated visit: it may have loaded only partly, or it may have completed before publication or status was lost. A finished report still uses exactly one completed attempt per condition; evidence from an abandoned attempt is never merged into the report.

Two parts of a visit are active rather than passive, and neither involves your data: the scanner types a synthetic, throwaway string into a few visible form fields to test whether keystrokes are captured and sent off the page (it never types anything about you), and in Consent mode it clicks the cookie banner’s “Accept all” or “Reject all” control. If no banner control is found, nothing is clicked and the report says so.

What is stored, and for how long

• A live, user-requested scan can be saved as a shareable report so its permalink works. Before public report bytes are written, URL credentials, fragments, and query values are removed; non-allowlisted path segments become markers such as {seg}, non-allowlisted subdomain labels are generalized, and unrecognized cookie names and storage keys become redaction markers. The scanner uses the exact submitted address to perform the visit; it is not written into the public report. Screenshots can appear in the immediate result, but are not persisted in the share report.
• Live share reports expire after about 7 days on the reference deployment (configurable by whoever runs the instance): an expired report's link stops working, any read of it removes the stored copy, and routine cleanup deletes expired copies that were never read again.
• A separate, deliberately published research corpus appears in the public directory. Those curated reports are versioned files with provenance sidecars and do not use the live-share expiry policy. The public directory describes the corpus currently retained under its own age, count, and cohort rules; reports cited by the corrections ledger are pinned against that automated pruning.
• This tab keeps a short-lived recovery pointer after a scan is accepted. Its browser sessionStorage record contains only the opaque job ID, the strict scanner-relative status path derived from that ID, a separate report ID, and acceptance/expiry timestamps. It never contains the scanned address, options, access key, Turnstile token, report, screenshot, or page evidence. The record is valid for at most 75 minutes and is deleted earlier after a readable result, failure, expiry, cancellation, or when you choose “Dismiss recovery.” It belongs to the current tab’s page session; treat the tab as private while recovery is active because the status identifier controls polling and cancellation on an open-access scanner.
• Optional restart-safe queue state is separate from a report. This mode remains disabled unless the deployment explicitly enables its durable-jobs flag, supplies the application encryption key and private scanner-coordinator credential, and passes the live lease-expiry recovery gate. When enabled, the application encrypts a job record before committing it to Cloudflare Durable Object storage and before returning the scan’s acceptance response. The encrypted record contains only the address’s scheme, host, and path (no query string or fragment) plus the selected device and run-mode options. It is kept for at most 75 minutes and removed from the active database as soon as the job succeeds, fails, expires, or is cancelled.
• The encrypted queue record never contains your IP address or client hash, Turnstile or access tokens, authorization or other request headers, cookies, screenshots, page evidence, or scan results. Bounded operational metadata—opaque job and report IDs, timestamps, status and progress, attempt count, and lease/fencing fields—is stored separately without application encryption and contains neither the target address nor a client identifier. After the active encrypted record is deleted, copies of its ciphertext may remain temporarily in Cloudflare’s platform recovery snapshots until Cloudflare’s own backup-retention window expires; those copies remain application-encrypted.
• Optional encrypted scheduled rescans are separate from live share reports. When the post-durability feature is explicitly enabled, one single-mode scan runs immediately and then at a fixed seven-day cadence, for at most five scheduled attempts or 30 days. Failed pre-admission attempts still consume that bound. The exact query-free address and its device/GPC options are application-encrypted with a separate Worker-only key. The service stores an opaque watch ID, only a cryptographic digest of the 256-bit control capability, and bounded scheduling/run metadata; it does not link the watch to an IP address, client hash, account, or Turnstile token. Capability-authenticated metadata and deletion remain available during rollback even if the feature or decryption key is unavailable, while target reads and scheduled execution fail closed. Deletion prevents future runs, but a durable scan already admitted may still finish under the ordinary job and report-retention rules.
• No report is linked to your identity, and reports do not record your IP address.

Rate limiting and abuse prevention

To keep the public scanner available, requests are rate-limited per client. Your IP address is used transiently for that limit and for the Turnstile bot check. It is not attached to stored reports and is not used to profile or track you across visits. The optional restart-safe job record does not copy or link either the IP address or its rate-limit client hash; a replay is the same admitted job, so it does not repeat the Turnstile check or charge the scan quota again. Scheduled rescan execution uses a small global daily budget rather than a stored per-IP identity.

Third parties

• Cloudflare provides hosting, network protection, and the Turnstile check. The Turnstile token (and, for that check, your IP) is processed by Cloudflare under its own terms. If restart-safe jobs are enabled, Cloudflare also hosts the application-encrypted active queue record and may retain encrypted copies in platform recovery snapshots for its backup-retention window. If scheduled rescans are enabled, Cloudflare likewise hosts their application-encrypted target/options and non-content scheduling metadata; recovery snapshots can temporarily retain encrypted copies after active deletion.
• The site you scan receives the automated visit and may log it like any other request, but it receives the scanner’s request, not your browser session or IP.

What this site does not do

• No accounts, sign-ups, or passwords.
• No advertising, analytics profiles, or cross-site tracking cookies of our own.
• No selling, renting, or sharing of scan data with data brokers.
• No storing of the query strings or fragments you remove before scanning.

Open source and self-hosting

Site Behavior Lab is open source, so all of the above is verifiable in the code rather than taken on trust. Anyone running their own instance controls their own storage and retention. This statement describes the reference deployment’s defaults and may be updated as the tool changes.