What Is Session Replay? How It Works, Explained

Session replay is a recording of one person using your product, reconstructed so you can watch it back: every page they visited, everything they clicked, scrolled and typed, in the order it happened. It answers the question analytics dashboards cannot — not how many users abandoned checkout, but what this one saw when they did.

This guide explains what a session recorder actually captures, why most modern tools record the DOM instead of video, what that means for privacy and performance, and what to look for when you pick one.

A session, and a replay of it

A session is one continuous visit: it starts when a page with the recording snippet loads and ends after a period of inactivity or when the tab closes. During that time the recorder observes the page and streams what it sees to a server. Later, a reviewer opens the session in a dashboard and a player rebuilds the page and animates the changes on a timeline, the way a video player would — except nothing was ever filmed.

Alongside the visual replay, a good tool extracts an interaction list: the clicks, navigations, errors and rage clicks in the session, so you can jump to the moment that matters instead of scrubbing through minutes of reading.

DOM recording versus video

The obvious way to record a screen is to capture pixels. Almost no web session replay tool does that, for three reasons.

• Size. A minute of screen video is megabytes; the same minute recorded as DOM changes is usually tens of kilobytes, because a page that is not changing costs nothing to record.
• Privacy. Pixels cannot be selectively masked after the fact. Structured data can: a recorder that knows a node is an <input> can replace its value with asterisks before it ever leaves the browser.
• Usefulness. A rebuilt DOM is inspectable. You can read the text a user saw, see which element they clicked, and — with the right tooling — translate the interface into another language, which is impossible with a picture.

So instead of filming, the recorder takes a full snapshot of the document once (a serialised copy of every element, attribute and text node) and then listens for mutations. Each change — a node added, an attribute updated, text edited, the mouse moved, the page scrolled — becomes a small timestamped event. This is the model that rrweb, the open-source library most tools build on, made standard; we cover it in detail in rrweb explained.

Replay is the inverse: the player rebuilds the snapshot into a real DOM inside an iframe, then applies the events in order at their original timing. Because it is a real DOM, the reviewer can resize, pause, and scrub, and the result stays sharp at any zoom.

What gets recorded

That last row deserves emphasis. A replay should never execute the recorded page. AnyReplay strips script bodies at record time, rebuilds scripts as <noscript> on replay, and renders the result in an iframe whose sandbox attribute is allow-same-origin with no allow-scripts — a sandbox iframe that cannot run code even if markup carried some. Reviewing a customer's session must not be a way for that customer's page to run inside your dashboard.

Privacy is part of the definition

A recorder sits inside somebody else's product and sees what its users type. Where the default sits, and who decides, matters more than any feature. There are two philosophies:

• Default-allow: record what people type, and mask the fields you mark. The replay shows what someone was trying to enter; marking the sensitive fields is your job.
• Default-deny: mask every input unless a field is explicitly unmasked. Safer to leave alone, at the cost of replays that cannot show what went into the form.

AnyReplay is default-deny: maskAllInputs is true, so a form replays as asterisks. What no configuration records is the floor the SDK enforces — passwords and one-time codes, card numbers, security codes, expiry dates and cardholder names, IBANs and routing numbers — replaced with asterisks in the browser before anything is sent. type="email" and type="tel" are ordinary fields. The rest is your decision: maskAllInputs: false makes it default-allow, maskAllTyping: true masks rich-text editors as well, an ar-mask class masks an element's text and a field's value, and an ar-block class removes an element from the recording entirely. How to mask sensitive data walks through the details, and session replay and GDPR covers consent, retention and where the data lives. The short version: recording is compatible with strict privacy law when PII is masked at the source, users can consent, and recordings expire — AnyReplay retains them for 14 days by default, configurable per organisation. See privacy features.

Performance: the recorder is a guest

A recording script runs on your customers' devices, on their networks. Two numbers to ask any vendor for: bundle size and what happens when the network fails.

AnyReplay's browser SDK is 34.8 KB gzipped, against a 45 KB budget that CI enforces — a build that exceeds it fails. Events are buffered and flushed in chunks (every 200 events or 5 seconds, whichever comes first), so the page is not making a request per click. If the ingest server is unreachable, the recorder backs off and sends the backlog once it is back. When the tab closes, the tail of the session is flushed with a keepalive request so the last few seconds are not lost.

You can also record fewer people. A sampling rate between 0 and 1 records that fraction of visitors, decided once per visitor rather than per page, so a recorded person stays recorded across their whole session.

Mobile is a different problem

None of the above transfers directly to native mobile apps, because there is no DOM. Most mobile replay SDKs fall back to periodic screenshots — expensive, unmaskable after the fact, and untranslatable. AnyReplay's React Native SDK takes a different route: it records the React element tree that the app committed, with real text and layout, producing a wireframe rather than a photograph. Session replay for React Native explains how, and the React Native feature page summarises what it captures.

Where replay fits next to analytics

Replay is not a substitute for product analytics. A funnel tells you where people drop; a heatmap tells you what a crowd does on one page. Replay tells you why one person did what they did — and it is the only one of the three that shows you a bug as the user experienced it. Most teams use replay to investigate what the aggregate numbers flagged; session replay vs analytics goes deeper on when each is the right tool.

What AnyReplay adds

Everything above is table stakes for a session replay tool. AnyReplay's particular bet is that the reviewer and the user often do not share a language. Because the recording is structured text rather than pixels, the interface strings in a session can be translated on demand — a support agent in Berlin can watch a Turkish user's checkout in German, with buttons and labels rendered in German, without anyone re-recording anything. That is session translation, and it is the reason the product records words rather than pictures on mobile too.

The Free plan is one project and 500 sessions a month, which is enough to see whether replay answers the questions your team is asking. Plans are on the pricing page.

Frequently asked questions