What is session replay?

How does session replay actually work?

A script in the page takes an initial snapshot of the DOM, then subscribes to two streams.

Mutation stream. A MutationObserver watches the document and emits a record every time the DOM changes: a node added, an attribute changed, text rewritten. Each record carries a timestamp and a reference to the affected node.

Event stream. Listeners capture clicks, scrolls, pointer movement, key input, viewport resizes, and navigation, each timestamped against the same clock.

Both streams are batched and sent to the vendor. On playback the tool rebuilds the initial snapshot in an isolated document and applies the recorded mutations and events in chronological order, at the original timing. What you watch is a deterministic rebuild of the page, not a recording of a screen.

Why do session replay tools not record video?

Three reasons, in order of weight.

Bandwidth and storage. Screen video at usable fidelity runs orders of magnitude larger than an event log. Uploading it from the visitor's browser would degrade the experience being measured, which corrupts the measurement.

Privacy control. A video frame captures whatever was on screen, including data the visitor typed. A DOM based capture can be instructed to never transmit the contents of a given element, because the tool controls serialization at the node level. Video offers no equivalent lever.

Queryability. Because the capture is structured, tools can answer "show me every session where someone rage clicked the pricing toggle" without a human watching anything. Video cannot be filtered that way.

What does session replay capture about your visitors?

What a replay tool records reaches well past clicks and scrolls.

Text inside form fields is the sharp edge. Default masking replaces input values with placeholder characters before transmission, so the value never leaves the browser. Masking that is turned off, or applied to the wrong selectors, sends real values to a third party.

What are the privacy obligations?

Session replay typically processes personal data, which brings it within the scope of GDPR for EU visitors, and configuring it lawfully is the site owner's responsibility rather than the vendor's.

Practical requirements:

1. Mask by default, unmask by exception. Every input, and any element that can render user data, starts masked. Unmask specific selectors deliberately.
2. Strip credentials from captured network activity. Authorization headers, cookies, and API keys should never reach the recording. Log status codes rather than response bodies.
3. Establish a lawful basis and record it. Consent, or legitimate interest supported by a documented assessment. Pick one and write it down.
4. Set retention deliberately. A window of one to three months covers diagnostic use. Indefinite retention is a liability with no analytical payoff.
5. Handle data residency. EU visitors generally need EU residency or a valid data processing agreement.
6. Exclude sensitive surfaces entirely. Account pages, anything behind authentication carrying health or financial data, and admin views.

A vendor's defaults are a starting point and not a compliance posture. Configure the six items above, then verify the result by recording yourself typing into your own forms and inspecting what the playback stored.

How do you run session replay on a Webflow site?

Install is the same script tag as any behavioral tool: Site Settings, Custom Code, Head Code, then publish. Custom code does not execute in the Designer canvas or in preview.

Webflow specifics worth planning around:

Mask Webflow form fields explicitly. Webflow forms render standard inputs, so vendor default masking usually catches them. Verify anyway, because a field built as a div with contenteditable or a custom component may not match the vendor's default selector rules.

Exclude the staging domain. Sessions on yoursite.webflow.io are your own team. Filter them or your sample is contaminated by QA behavior.

Interactions replay only if the DOM changed. Webflow interactions driven by CSS transforms and class changes replay correctly, since those are DOM mutations. Effects driven by canvas or WebGL do not, and appear frozen in playback.

Republishing does not break existing recordings, because each recording carries its own DOM snapshot. This is the one place replay is more durable than a heatmap.

Which term should you use, replay or recording?

Both terms name the same product, and no vendor enforces a difference. The split this glossary keeps is the useful one: session replay is the capture and reconstruction technology, session recording is the artifact it produces and the practice of watching it. Reach for "replay" when the question is about capture, masking, storage, or playback fidelity. Reach for "recording" when the question is which sessions to watch and what they showed. Session recording covers that second half.

Related terms

Session recording · Rage click · Dead click · Website heatmap · User behavior analytics

Deeper reading: Diagnosing why users drop off using session recordings. Service: Conversion Rate Optimization.

FAQ

Does session replay record passwords?

It should never transmit them. Password inputs are masked by every mainstream tool by default, and the masking happens in the browser before anything is sent. Verify on your own site by recording a session, typing into the field, and inspecting the playback.

Is session replay legal under GDPR?

Yes, when configured correctly. It processes personal data, so it requires a lawful basis, default PII masking, a defined retention period, and appropriate data residency. The vendor supplies the controls. Configuring them is your obligation.

Does session replay slow down a site?

The capture script adds weight and continuous background work, more than a heatmap-only script because it observes every DOM mutation. Load it asynchronously, sample rather than recording 100% of sessions on high-traffic pages, and measure the delta rather than assuming it is free.

Why do embedded widgets appear blank in playback?

Because the capture script cannot read inside a cross-origin iframe. Anything embedded from another domain, such as a payment field, a booking widget, or a chat window, is opaque to the observer watching your DOM, so it replays as an empty box. Sessions that fail inside an embed need the embed provider's own logs, not your replay tool.

Sources

• Microsoft Clarity, open-source library: github.com/microsoft/clarity. States that the capture package "tracks user interactions as well as layout changes", that the decode package converts incoming data back to its original format, and that the visualize package "takes the decoded data from clarity-decode and turns it back into pixel-perfect session replay". This is the same code that powers the hosted Clarity product. Read 2026-08-15. Supports the capture-and-rebuild model described above, as against video recording.
• Microsoft Clarity, same repository, privacy notice: "By default sensitive content on the page is masked before uploading to the server. Additionally, Clarity offers several masking configuration options to ensure you are in full control of your data." Read 2026-08-15. Supports default masking being a vendor control whose configuration remains the customer's.