What is session replay?

How it works

A small script on your site does three things:

1. Takes a snapshot of the page when it loads: every element, its text and attributes, and the styles that apply.
2. Records changes from then on. Browsers report every change to the page through an API called MutationObserver, so the script notes each added, removed or edited element, along with mouse movement, clicks, scrolling, typing and resizing, each with a timestamp.
3. Uploads the log in small batches to a server.

To play a session back, a player builds the snapshot inside a sandboxed frame and applies the changes in order, moving a fake cursor along the recorded path. Seeking to a point in the middle means rebuilding the page up to that moment.

Because it is a log of changes and not pixels, a recording is small, text in it can be masked before upload, and you can inspect the replayed page like a real one.

What it is good for

• Reproducing bugs. A support ticket says “checkout is broken”. The replay shows the exact clicks, the form values (masked) and the console error that followed.
• Finding friction. People clicking something that is not a link, scrolling past the button they need, or rage clicking on a control that does nothing.
• Checking a release. Watch a handful of real sessions on a new page before trusting the numbers.
• Supporting customers. Search by the account ID from the ticket and watch their session instead of asking for screenshots.

It is not a replacement for analytics. Replay answers “what happened in this visit”; analytics answers “how often does it happen”. Watching ten sessions is useful. Watching a thousand is a sign you need a metric.

What makes a replay accurate

The hard part of session replay is making the replay look like what the visitor saw. Common reasons replays break:

• Hover and focus styles. CSS :hover cannot be triggered by a script, so dropdown menus stay closed unless the player imitates the hover state.
• CSS-in-JS. Libraries like styled-components and Emotion write rules straight into the stylesheet object, not into <style> text, so a naive recorder misses them.
• Shadow DOM and web components. Their content and styles live outside the main document.
• Assets that change. Most tools, including Replayowl, load images and fonts from your site at replay time. If you redeploy, old replays can look different.

The quickest test is to record a page from your own site that uses these things and compare. Replayowl’s live demo lets you do that with its recorder in a few seconds.

Privacy

Session replay can capture anything on screen, so it needs care:

• Mask in the browser. Text should be masked before it leaves the visitor’s device, not on the server. Replayowl masks every text input, email addresses and long digit runs by default. See masking and privacy.
• Know where recordings go. With a hosted tool, every session goes to the vendor’s cloud. With a self-hosted tool, it goes to your own storage.
• Check whether you need consent. In the EU and UK this depends on how the script works and what you use the recordings for. See session replay and GDPR.

Performance

The recording script runs on every page for every visitor, so its weight matters. Check three things: the script’s size, whether it batches and compresses uploads, and how much work it does when the page changes a lot. Replayowl’s recorder is about 8 KB gzipped with no dependencies and uploads one gzipped batch every 4 seconds.

Hosted or self-hosted

Hosted tools such as Hotjar, Microsoft Clarity, FullStory and LogRocket are quicker to start with and often include heatmaps and analytics. Self-hosted tools keep recordings on your infrastructure and have no per-session price, but you run them. Our comparisons cover both: Hotjar alternatives, open source session replay, and all comparisons.