How Session Replay Works, and What It Cannot See

What is session replay?

In web analytics, session replay is a technique that reconstructs a user's visit as a watchable playback by recording DOM changes and input events instead of filming the screen. The recorder serializes the page's DOM once at load, then streams every subsequent mutation, click, scroll, keypress and viewport change as a timestamped event. A player later applies that event stream to a rebuilt copy of the page inside a sandboxed iframe, which is why the playback looks like video but weighs a fraction of one.

That distinction drives everything else, from what a replay proves to what it costs to store.

How does session replay record a page without video?

A session replay recorder captures state, not pixels. On page load it walks the DOM tree and serializes every node into a JSON structure, assigning each node a stable numeric id. That first payload is the full DOM snapshot, and everything after it is a diff.

From that point the recorder attaches a MutationObserver and a set of event listeners. Each change becomes a small record: node 412 gained a child, node 205 had its text replaced, the window scrolled to y=1,200 at millisecond 8,431. The open-source library rrweb established the format most vendors follow, including the id-per-node model and the snapshot-plus-increments split.

Playback reverses the process. The player builds a document from the snapshot, mounts it in an iframe with scripts disabled, then applies mutations in recorded order against a virtual clock. Nothing on the replayed page executes, and the cursor you watch is a drawn overlay, not a captured pointer.

What can a session replay capture, and what does it miss?

A session replay captures anything expressed in the DOM of the recorded page, and nothing that lives outside it. Because the recorder reads the same DOM the browser renders, content injected by a browser extension appears in the replay exactly as the visitor saw it, which explains bug reports no one on the team can reproduce.

The gaps are specific:

• Canvas and WebGL surfaces render as blank boxes unless the recorder is configured to snapshot them, because their contents are not DOM nodes.
• <video> and <iframe> content from another origin cannot be read, so the replay shows the element frame with nothing inside.
• Native browser UI never appears: autofill dropdowns, alert() dialogs, the print sheet, the download bar, devtools.
• Anything in another tab, another window, or the operating system is out of scope.
• Server state stays invisible. The replay shows that a form returned an error, not which database constraint rejected it.

One failure mode surprises teams months later. Images, fonts and stylesheets are stored as URLs, not as bytes, so a deploy that changes a stylesheet makes older replays render with the new styles. A replay from six months ago is a record of structure and behavior, not of exact appearance.

How does masking protect personal data in a session replay?

Masking replaces sensitive values inside the browser before any event is sent, so the server never receives the original text. A recorder applies rules as it serializes each node: password inputs are dropped by default, elements carrying a class such as .mask have their text swapped for asterisks, and blocked elements become an empty placeholder box that preserves layout.

Two policies behave differently under pressure. A blocklist masks the fields you remembered to mark, and leaks the field a developer adds next sprint. An allowlist masks everything by default and un-masks the elements you name, which produces uglier replays and no surprises. Pick the allowlist for any surface touching payment, health, account or support data.

Flowsery is cookie-free, EU-hosted and GDPR by design, and ships one script under 10 KB.

Blocklist vs allowlist masking

Blocklist

• Masks only the fields marked today
• Leaks the field a developer adds next sprint

Allowlist

• Masks everything by default
• Un-masks only the elements named
• Uglier replays, no surprises

How much storage does a session replay need?

Storage scales with event volume, not with session length in wall-clock time. A visitor reading an article for ten minutes produces almost no mutations; a visitor dragging items around a canvas app for ninety seconds produces tens of thousands. The estimate is:

monthly bytes = sessions recorded x events per session x compressed bytes per event

Work one example. Assume 50,000 recorded sessions a month, 4,000 events per session, and 200 compressed bytes per event:

4,000 x 200 = 800,000 bytes, so roughly 800 KB per session. 800 KB x 50,000 = 40,000,000 KB, so roughly 40 GB per month.

The same 50,000 sessions captured as 720p video would run into terabytes. That ratio is why replay tools price on session counts and retention windows instead of gigabytes, and Flowsery sets plan limits as quotas covering analytics sessions, session recordings, AI-analyzed sessions and replay retention in months.

Should you sample sessions or record all of them?

Sampling trades diagnostic coverage for cost, and it fails on exactly the sessions you need. If a checkout bug affects one visitor in 400 and you record 10 percent of traffic, you capture the bug once every 4,000 sessions and cannot confirm a fix without waiting weeks. Rare events are the reason replay exists, and rare events are what sampling deletes.

Flowsery records every user session with no data sampling, and connects to replays already recorded in PostHog or Amplitude without re-instrumentation. If a budget forces a sampling decision anyway, keep 100 percent of sessions that touch checkout, signup, and any flow that emitted a JavaScript error.

How is session replay different from screen recording and a heatmap?

Session replay, screen recording and heatmaps answer three questions from three data sources. Screen recording captures encoded pixels of whatever a capture API sees. A heatmap aggregates coordinates from many visitors into one image and keeps no individual path.

Question	Session replay	Screen recording	Heatmap
What is stored	DOM mutations and input events as JSON	Encoded video frames	Aggregated coordinates and counts
Size per session	Kilobytes	Megabytes	No per-session artifact
Text after capture	Real, selectable DOM text	Pixels only	Not retained
Who starts it	The page script, automatically	A person, deliberately	The page script, automatically
Scope	The recorded page only	The whole screen or window	The recorded page only
Shows one person's path	Yes	Yes	No, it merges everyone
Answers	Why did this visit fail	What did this person say while doing it	Where does everyone click

Use a heatmap to decide where to look, and a replay to find out what happened there. A heatmap shows a cold CTA; only a session recording of a visitor who scrolled past it tells you the button sat behind a sticky header on that breakpoint.

Where do teams use session replay in practice?

Teams use replay to close the gap between an error report and a reproduction. A stack trace names the line that threw; the replay preceding it shows the eleven clicks that put the app in that state. The same holds for silent failures, where nothing throws and the only evidence is a visitor clicking a disabled button six times.

Watching replays one by one stops working past a few hundred sessions a day, so detection matters more than playback. Flowsery's AI session replay detects rage clicks, dead clicks, JavaScript errors, drop-offs and broken flows automatically, groups matching sessions into one issue, and ranks issues by how many users hit them. Each issue lands in Slack, Linear or Jira with the replay and steps to reproduce attached, and tagging @flowsery in Slack opens a draft pull request in your GitHub repo. Those frustration signals turn recordings into a ranked queue.

Frequently asked questions

Is session replay the same as screen recording?

No. Screen recording stores encoded video frames of a screen or window, while session replay stores DOM mutations and input events and rebuilds the page from them. The consequences are size, kilobytes against megabytes, and scope, since replay sees only the recorded page.

Does session replay record passwords?

Recorders drop password input values by default, so the field appears masked and the real value never leaves the browser. Other sensitive fields stay unprotected unless you mark them, which is why an allowlist that masks everything and un-masks named elements beats marking fields one at a time.

Why do old replays look broken?

Replays reference stylesheets, fonts and images by URL instead of storing their bytes. A CSS deploy or a deleted CDN asset makes older replays render with the new styles or with missing images. The DOM structure and interaction timeline stay accurate.

Can session replay see inside an iframe?

A recorder can capture same-origin iframes by instrumenting them alongside the main document. Cross-origin iframes are blocked by the browser's security model, so an embedded payment form or third-party widget from another domain appears as an empty frame in playback.

How long should replays be kept?

Retention should match the shortest window in which you act on the data, since every extra month adds cost and privacy exposure. Flowsery expresses replay retention in months as part of the plan quota.

Does session replay slow down a page?

The recorder's cost comes from serializing the initial DOM and observing mutations afterward, so heavy single-page applications with large trees pay more than static pages. Script weight is the part you control at install time: Flowsery ships one script under 10 KB.

Does Flowsery use cookies to record sessions?

Flowsery records sessions without cookies, runs on EU-hosted infrastructure, and is built GDPR by design. The script that captures the DOM snapshot and mutation stream ships under 10 KB, so the recording pipeline itself carries no cookie dependency.

Can a browser extension show up in a session replay?

Yes, because the recorder reads the same DOM the browser renders, and an extension's injected content becomes part of that DOM. That is why a bug report can describe something no one on the team can reproduce, since the extension only exists in that one visitor's browser.

Can session replay connect to tools like PostHog or Amplitude?

Flowsery connects to replays already recorded in PostHog or Amplitude, so a team does not need to re-instrument a site that already sends events to one of those platforms. It records every session with no sampling, which keeps the rare checkout or signup failures that a partial capture would miss.

Can session replay flag problems automatically instead of watching every recording?

Flowsery's AI session replay detects rage clicks, dead clicks, JavaScript errors, drop-offs and broken flows, then groups matching sessions into a single issue and ranks issues by how many users hit them. Each issue reaches Slack, Linear or Jira with the replay and reproduction steps attached, and tagging @flowsery in Slack opens a draft pull request in the connected GitHub repo.