What never reaches your replays
The data SessionSight removes from every session, no matter which privacy mode you pick
Last updated:
Everything listed below is removed from every session, on every page of your site, before any data leaves the browser. None of it can be turned off, and the privacy mode you picked during onboarding does not change any of it.
Three different things happen, depending on what we find:
- Passwords and sensitive patterns are redacted. The match is replaced with the literal text
[REDACTED], which is what shows up in the replay. - URL query strings are stripped. Anything after a
?in a URL is dropped before the URL is recorded. - Image, video, and audio sources are stripped. The replayer renders a “media hidden” placeholder where the original asset would have been. You can opt back in for specific assets with
data-ss-allow.
Passwords (redacted)
Anything typed into a password field is replaced with [REDACTED] before the data leaves the browser. The original length is not preserved, so the captured value cannot be used to guess how long the password was.
This also covers fields that started as passwords and were later switched to a different input type during the same session.
Sensitive patterns (redacted)
The SDK scans every piece of text and every input value for known sensitive patterns. When it finds one, the match is replaced with [REDACTED] before the data leaves the browser. That placeholder is what shows up in your replays.
Personal information
| What | What we look for |
|---|---|
| Credit card numbers | 13 to 19 digits that pass a checksum, so order numbers and tracking codes do not get caught by accident |
| Social Security numbers | Standard 3-2-4 digit shape |
| US tax IDs (ITIN) | Same shape as a Social Security number, in the IRS-issued ranges |
| UK National Insurance numbers | The full code with the letter suffix |
| Canadian Social Insurance numbers | Nine digits in the standard 3-3-3 grouping |
| IBAN bank account numbers | Country code + check digits + account number |
| Email addresses | Anything in the standard [email protected] shape |
| Phone numbers | US 10-digit and international +country code formats |
| IP addresses | IPv4 (192.168.1.1) and IPv6 (2001:db8::1, ::1, etc.) |
| US street addresses | Best-effort: <number> <name> <St/Ave/Rd/Blvd/...> with optional unit |
The US street address detector is intentionally simple. It catches the most common shape, but addresses outside the US, addresses without a recognized street suffix, and addresses split across multiple form fields will not match. If you need stronger guarantees, wrap the field in data-ss-mask so the contents are scrambled regardless of pattern.
API keys and other credentials
Useful if your app has internal tools, dashboards, or admin pages where staff might paste keys into a form.
| What | Examples |
|---|---|
| Private keys | -----BEGIN PRIVATE KEY----- blocks (RSA, OpenSSH, EC, etc.) |
| Auth headers shown in text | Bearer ..., Basic ..., Token ..., Digest ... |
| URLs with embedded passwords | https://user:pass@host becomes https://[REDACTED]@host |
| JWTs | The standard three-part eyJ... token shape |
| Anthropic keys | sk-ant-... |
| OpenAI keys | sk-... |
| Stripe keys | Live and test keys (sk_live_..., pk_test_..., whsec_..., etc.) |
| GitHub tokens | ghp_..., gho_..., and the rest of the prefix family |
| Slack tokens | xoxb-..., xoxp-..., etc. |
| AWS access keys | AKIA... keys and the signature parameters in presigned URLs |
| Google API keys | AIza... |
URL query strings (stripped)
Pages often put session tokens, password reset codes, and personal data into the part of the URL after the ?. SessionSight drops that part off every URL the SDK sees, including the page address itself, link href values, and form action values. The path part of the URL stays so you can still tell what page someone was on.
Images, video, and audio (stripped)
Customer apps render uploaded documents, identity scans, voice notes, and other user-supplied media that the SDK has no way to inspect for sensitive content. So by default, every <img>, <video>, <audio>, <source>, SVG raster <image>, and inline background-image: url(...) reference is cleared from the recording before any event leaves the browser. The replayer renders a small “media hidden” placeholder in the same space, so layout fidelity is preserved.
This covers both URL references (src="https://...") and embedded bytes (src="data:image/...;base64,...", blob:...). Embedded bytes always strip, since they would otherwise persist on SessionSight’s servers.
Fonts (@font-face src: url(...)) are preserved automatically so replays render in your typography. Inline SVG icons (<svg><path>...</path></svg>) and <use href="#sym"> symbol references are not affected — the strip targets media content, not vector geometry.
If a particular image or media element is safe to show in replays (a brand logo, a marketing video, a product hero shot), mark it with data-ss-allow. The opt-in only honors URL references — embedded bytes still strip.
We do this twice
Everything above runs in two places:
- In the browser, before any event is sent.
- On our servers, the moment incoming data lands, before it is queued or stored.
The second pass exists so that even if someone bypassed the SDK and posted directly to our ingest endpoint, the same patterns would still be caught.
What this does not cover
Everything above happens automatically. If you want to mark a specific section of your site as always-scrambled, always-readable, or completely hidden, see Privacy & Data Tags.