Recording and privacy settings

The Browser Client combines Cloud transport settings with rrweb recorder settings. Set privacy rules before enabling capture on production pages, then test the stored replay rather than assuming the live page and replay expose the same data.

Recording governance and lifecycle

Technical masking is one part of a production recording policy. Before capture, establish consent or another lawful basis for each page and data category. Define access control for recordings and replays, restrict access to authorized workspace roles, document how access is reviewed, and make sure operators use recordings only for the approved purpose.

Choose retention based on the controls available for your rrweb Cloud plan and workspace and on your own policy; do not assume a universal default. Define how your team handles applicable recording access and deletion requests, including recordings grouped by application metadata.

When a person withdraws consent, stop capture immediately and prevent automatic restart. For the Browser Client, stop(true) stops recording and clears the stored recording ID for the next start. Withdrawal does not by itself delete recordings already stored, so run the separate deletion workflow required by your policy.

Which layer owns a recording option?

Browser Client-owned options control Cloud integration: publicApiKey, serverUrl, includePii, meta, autostart, jsSource, and jsEntrypoint. The client also owns recording IDs, WebSocket delivery, and HTTP fallback.

All other rrweb recording options are forwarded options passed to record(). This includes blocking, masking, sampling, canvas, iframe, snapshot, stylesheet, and plugin settings. The Browser Client replaces emit with its Cloud transport but still calls a custom emit callback when one is supplied.

What does rrweb Cloud record by default?

The Browser Client applies these Cloud defaults only when you do not provide the corresponding rrweb option:

• maskAllInputs: true masks every supported input type, including password fields.
• slimDOMOptions: 'all' removes nonessential DOM data to reduce stored volume.
• inlineStylesheet: true preserves stylesheet rules needed for stored replay.

The remaining defaults come from rrweb. Elements with class rr-block are blocked, text with class rr-mask is masked, and password inputs remain masked even if you explicitly set maskAllInputs: false without changing maskInputOptions. Canvas recording and cross-origin iframe recording are off by default.

Options you pass take precedence. Treat that flexibility as a privacy decision: overriding a safe default can increase captured data.

Block or mask sensitive content

Use blockClass or blockSelector when neither the contents nor DOM structure of a region should be recorded. Use maskTextClass, maskTextSelector, maskAllInputs, or maskInputOptions when replay needs the structure but not the original value.

start({
  publicApiKey: 'public_key_rr_your_key',
  blockSelector: '[data-private]',
  maskTextSelector: '[data-mask]',
  maskAllInputs: true,
});

Blocking and masking are supported directly. Custom functions such as maskTextFn and maskInputFn are also forwarded, but need application tests because a selector or callback can miss dynamically rendered content.

Continue in the rrweb Library privacy guide for the complete behavior of these controls, then verify the Cloud replay with representative synthetic data.

Sample events to reduce storage volume

The sampling option can reduce mousemove, scroll, input, media, and canvas event volume. Snapshot checkout options can add periodic full snapshots, trading storage for more resilient replay boundaries. These options are supported and forwarded without a Cloud-specific sampling layer.

Continue in the rrweb Library record options and storage optimization recipe. Change one signal at a time and check that the resulting replay still answers your debugging questions.

Are images, audio, and video captured?

In the current stable Browser Client and rrweb recorder, captureAssets is not yet supported. It has no image, audio, or video defaults, and passing a captureAssets object does not enable asset byte capture. Use the supported recorder options below and re-check the versioned package documentation before adopting a future asset API.

• inlineStylesheet: true is the Browser Client default. It captures accessible stylesheet rules needed for replay, which can increase snapshots but avoids depending entirely on a stylesheet changing later.
• inlineImages: false is the rrweb stable default. Replays normally retain image URLs rather than embedding image bytes. The deprecated inlineImages: true option attempts data-URL capture, which can greatly increase storage volume and can fail for cross-origin or protected images because of browser security rules.
• recordCanvas: false is the rrweb stable default. Enable it only with the privacy, volume, and compatibility review described in the Canvas section below.
• For audio and video elements, rrweb records element attributes, playback state, time, volume, and user media interactions. It does not store the audio and video media bytes. Replay therefore depends on the referenced media remaining reachable and authorized.

Asset URLs themselves can contain identifiers, and inlined images or canvas pixels can reveal sensitive content that DOM masking does not cover. Block sensitive media regions, test authenticated and cross-origin assets, and measure real recording sizes before rollout.

Continue in the rrweb Library record options for the currently supported inlineStylesheet, inlineImages, recordCanvas, and media behavior. There is no current Library captureAssets recipe because that option is not part of the stable recorder API.

Record canvas content

Canvas recording is supported by rrweb but disabled by default. Enabling recordCanvas can add substantial data and may capture sensitive pixels, drawings, charts, or documents. WebGL contexts can require further compatibility work, and protected or cross-origin media may remain unavailable because browser security rules prevent reading their pixels.

Continue in the rrweb Library canvas recipe for the required options and limitations. This is an extra integration step, not an automatic Cloud feature.

Are iframes recorded?

Same-origin iframe content can be observed under normal browser access rules. Cross-origin iframe contents are unsupported by default: the parent page cannot inspect a document from another origin. recordCrossOriginIframes: true must be set on both the parent page and the child frame, with rrweb running in each. The parent receives the events and the child sends them by postMessage.

Continue in the rrweb Library cross-origin iframe recipe before enabling it. Third-party frames that you cannot instrument remain unsupported; block the frame or accept a placeholder.

Are console logs and network requests recorded?

Only when the console and network plugins are enabled; payload bodies are never captured by default.

Console and network capture are not enabled by the Browser Client. Both require rrweb plugins and therefore extra integration steps. Logs, request bodies, response bodies, headers, URLs, and error objects can contain tokens or personal data; redact or allowlist fields before they become rrweb events.

Continue in the rrweb Library console recipe and network recipe. Cloud stores plugin events it receives, but it does not infer which payload fields are safe.

Add custom events to a recording

Custom events are supported through the Browser Client's addCustomEvent(tag, payload) helper or rrweb's equivalent API. Keep payloads small, version their shape, and exclude secrets and raw user input.

Continue in the rrweb Library custom event recipe for event semantics. No plugin is required for ordinary custom events, but your replay UI needs extra integration steps if it should render them specially.