Replay privacy & masking
How session replay protects user data: masked inputs by default, always-masked passwords, and declarative masking classes.
Session replay reconstructs what a visitor saw and did, built on rrweb. Because a recording can contain whatever was on screen, OakData masks sensitive content aggressively by default and gives you declarative control over the rest.
Replay is opt-in
Recording is off until you enable itfor a project from the dashboard. The SDK fetches its replay configuration from the server at runtime, so turning replay on or off — and changing masking rules — doesn't require a code change or redeploy.
What's masked by default
| Default | Type | Description |
|---|---|---|
All input values | masked | Text typed into inputs, selects, and textareas is masked in the recording unless you explicitly turn input masking off for the project. |
Passwords | always masked | Password fields are never recorded — even if input masking is turned off. There is no setting that exposes them. |
Structure, not secrets
Replay captures the DOM structure, layout, and interactions — clicks, scrolls, navigations — so you can see how someone used the page. Masking hides the content of sensitive fields while keeping the shape of the page intact.
Declarative masking classes
Add these CSS class names to any element to control how the recorder treats it. They're also documented under autocapture & data attributes.
| Class | Type | Description |
|---|---|---|
oak-mask | mask text | Replaces the element's text with blocks in the recording. |
oak-ignore-input | drop value | Records the input but not what was typed into it. |
oak-no-capture | block subtree | Excludes the element and everything inside it; rendered as a placeholder. |
<p class="oak-mask">Balance: $12,400.55</p>
<input class="oak-ignore-input" name="card-number" />
<section class="oak-no-capture"><BankDetails /></section>Projects can also configure CSS block selectors centrally from the dashboard, so you can suppress whole categories of elements without editing markup.
How recordings are stored & served
The recorder streams rrweb events into gzipped NDJSON chunks in object storage. When you fetch a replay through the REST API or the get_replay MCP tool, you get the recording metadata plus short-lived signed URLs (valid ~30 minutes) for each chunk — a player fetches, gunzips, and merges them by timestamp. URLs expire, so fetch them fresh each time you play a recording.