Usero Journal

What Is Session Replay? (And When You Actually Need It)

Q: What is session replay?

Session replay is a tool that reconstructs what a user did in your web app, page by page and click by click, by capturing the DOM and user events on the client and replaying them as a video-like timeline in your dashboard. It is not a video recording; it is a reconstruction from structured data.

Q: Is session replay the same as a screen recording?

No. A screen recording captures pixels with a video codec. Session replay captures the structure of the page (the DOM) plus events (clicks, scrolls, input, network) and rebuilds the page in your browser at playback time. That is why replays are tiny, searchable, and let you inspect the DOM as it was at any point in the session.

Q: How does session replay work technically?

On first paint, the SDK serializes the full DOM. From then on, it captures mutations (DOM changes, scrolls, clicks, input) as a stream of structured events. The events are batched, compressed, and uploaded. The viewer downloads the snapshot, applies the events in order, and renders the result inside an iframe so it looks like a video.

Q: Is session replay a privacy risk?

It can be if you do nothing. Every modern session replay tool masks input fields by default and lets you mask any DOM node by selector or attribute (data-private, .pii, etc). Configure masking before you turn replay on, not after. Also check your DPA, consent flow, and data residency. If you collect health, financial, or government data, audit the masking config end-to-end.

Q: Does session replay slow down my site?

A well-built SDK adds 30 to 80 KB gzipped and uses ~1 to 3 percent CPU during active sessions. Network upload is throttled and batched. The performance impact is usually invisible on modern devices. On low-end mobile or pages with thousands of DOM nodes per frame (heavy data tables), you may see a small hit; sample at 10 to 20 percent of sessions there instead of 100.

Q: When do I actually need session replay?

When you are triaging a bug report and the words are not enough, when you have a conversion drop and want to see what users hit before bouncing, or when you are onboarding a new user-facing feature and need to see how real users navigate it. If your support volume is low and your funnels are clean, replay is a nice-to-have, not a must.

Q: What is the best session replay tool?

For pure session replay at scale, FullStory and LogRocket are the heavyweights. For product analytics with replay built in, PostHog is the value pick. For lightweight site replay paired with heatmaps, Hotjar. For replay attached to user feedback so the bug report and the recording arrive together, Usero.

Will Smith·May 19, 2026·11 min read

Session replay is a tool that reconstructs what a user did in your web app by capturing the DOM and user events on the client, then replaying them as a video-like timeline in your dashboard.

Critically, it is not a screen recording. There is no video codec involved. A small SDK in your page captures the DOM structure once, then streams events (mutations, clicks, scrolls, input) as the user interacts. The viewer downloads those events and reconstructs the page inside an iframe. That is why replays are small, searchable, and let you inspect the live DOM at any point in the session.

This piece covers what session replay actually is, how the technical pieces fit together, the privacy implications you have to take seriously, when you genuinely need it versus when it is overkill, and the five vendors worth your time.

How Session Replay Works

The mental model that makes everything click: a session replay is a Git history for the DOM, with user events interleaved. You snapshot once, then store the diffs.

1. The initial snapshot

When the SDK loads, it walks the DOM and serializes every node into a tree of plain objects. Tag, attributes, text content, computed styles where they matter. CSS is captured by URL where possible, inlined where not. This snapshot is the “starting frame” for the replay.

2. The event stream

A MutationObserver watches the DOM. Every add, remove, attribute change, or text change becomes an event with a timestamp. The SDK also listens for mouse events, scrolls, input (masked by default), viewport resizes, and console messages. Each event is small (often under 1 KB) and gets batched into bursts every few seconds.

3. Compression and upload

Bursts are compressed (usually gzip or brotli) and uploaded to the vendor backend. A typical 5-minute session lands at 200 KB to 2 MB depending on how chatty your UI is. Animated dashboards with re-rendering charts push the upper end; mostly static pages live near the lower.

4. Reconstruction in the viewer

When you open a replay, the viewer creates a sandboxed iframe, injects the initial DOM snapshot, then applies events in order at the recorded timestamps. You see the page render, the user move the mouse, type into fields, scroll, click. Open devtools on the iframe and you can inspect the DOM as it was at the exact moment the bug happened.

Session replay is not a video. It is a deterministic re-execution of state changes. That is what makes it tiny, indexable, and useful.

Common Misconceptions

Half the bad takes on session replay come from people who think it is something it is not. Three to get out of the way.

“It is screen recording.” It is not. No video, no pixels, no screen-capture API. If you turn off the page’s JavaScript, replay sees nothing. The corollary: replay cannot capture third-party iframes (Stripe checkout, Google reCAPTCHA) and cannot capture content rendered into a canvas tag without special handling.
“It records passwords.” By default, every modern replay SDK masks the value of input fields and lets you mask any DOM node by class or attribute. Password fields are masked at the engine level. The risk is custom inputs you build yourself that bypass the standard input tag, not the standard ones.
“It is heavy.” A modern SDK is 30 to 80 KB gzipped and uses 1 to 3 percent CPU. Compare against the average analytics + tag manager + chat widget stack already on most sites and replay is rarely the worst offender.

Privacy (The Part Most Teams Get Wrong)

Session replay is one of the strictest categories under GDPR, CCPA, and HIPAA because the data being processed is, by construction, everything a user did. Get this part wrong and you have a class-action footnote. There are four levers, and you should pull all of them before you turn replay on.

Mask sensitive nodes. Add data-private or the vendor’s equivalent attribute to any element holding names, emails, account numbers, health details. The SDK replaces the content with placeholders before upload. Audit the result in your own dashboard before going live.
Block sensitive pages entirely. Don’t record on/billing, /account, /checkout. Most SDKs let you pass a URL blocklist on init. Cheaper than masking individual fields and harder to mess up.
Get consent where the law requires it. EU users: opt-in cookie banner with a real reject button. California: a do-not-sell link that actually works. The vendor will not handle this for you. It belongs in your consent management tool.
Sign a DPA and check residency. Any vendor processing this kind of data must offer a Data Processing Agreement. EU customers will want EU data residency. If the vendor cannot give you both in writing, do not deploy.

When You Actually Need It

Session replay is a power tool. It earns its keep in a few specific moments and is dead weight outside them.

Triaging a vague bug report. “The button did not work” becomes a 90-second replay where you see exactly which button, in what state, after what sequence. The single highest-value use case.
Diagnosing a funnel drop. Conversion fell 8 percent last week. Replays of users who bounced at step three show you a layout regression on Safari iOS. Numbers tell you something is wrong; replay tells you what.
Validating a new flow. You ship onboarding v2. Watch ten real first-run sessions before celebrating. The patterns you missed in QA show up in the first hour.
Rage clicks and dead clicks. Most replay tools auto-flag sessions where users click the same element 5+ times in 2 seconds, or click on a non-interactive element. Sort by these and you find UX bugs in minutes.

When It Is Overkill

Under 1,000 monthly active users. Volume is too low. Better to DM your users and watch them work over Zoom for an hour. You will learn more.
Static marketing sites. Heatmaps and scroll depth (Hotjar, Microsoft Clarity) give you 80 percent of the value at 20 percent of the complexity.
Heavy regulated data with no engineering bandwidth to configure masking. If you cannot dedicate an afternoon to mask configuration plus audit, postpone until you can.

Session Replay Tools At A Glance

Starting prices are monthly USD, early 2026. Replay is often bundled with analytics or feedback, so direct comparison is inexact. Confirm on the vendor site.

Tool	Starts at	Free tier	Bundled with	Sweet spot
FullStory	Custom (enterprise)	No	Digital experience analytics	Enterprise SaaS
LogRocket	$99	1k sessions/mo	Error tracking, performance	Engineering-led teams
Hotjar	$32	Yes (35 sessions/day)	Heatmaps, surveys	Marketing and growth
PostHog	$0, then usage	5k replays/mo	Product analytics, flags	Product engineers
Usero	$0, paid from $19	Yes (real)	Feedback widget, roadmap	Bug-report attached replays

The Five Worth Looking At

FullStory

custom (enterprise)

The heavyweight

FullStory is the category leader. Sophisticated frustration signals, deep funnel analysis, retroactive search across every recorded session. Built for teams with a CX or research function.

Pricing is opaque (you talk to sales) and the platform is overkill for anything under a few hundred thousand monthly sessions. If you are a small team and someone tells you to “just use FullStory,” politely decline.

Best for

Mid-market and enterprise teams that want digital experience analytics, not just replay.

LogRocket

from $99/mo

The engineering-led pick

LogRocket sits closer to Sentry than to Hotjar. The replay viewer puts console errors, network requests, and Redux state next to the timeline. If your debug loop is “error in Sentry, then where in the user journey,” LogRocket collapses that into one screen.

Heavier SDK, more expensive than the analytics-leaning competition. Worth it if your team is engineer-heavy. Less so for marketing.

Best for

Engineering teams that want replay glued to error tracking and performance metrics.

Hotjar

from $32/mo

The marketing-team default

Hotjar leans into heatmaps and surveys with replay as a complementary feature. The free tier (35 sessions a day) is generous enough to evaluate properly. Easy to set up and a small marketing team can drive it without an engineer.

Not the tool to reach for if you need engineer-grade debugging. The replay viewer is good but does not surface console or network detail like LogRocket.

Best for

Marketing and growth teams that mostly want heatmaps and lightweight session recordings.

PostHog

free, then usage-based

The product-engineer value pick

PostHog bundles replay into a wider product analytics suite. Self-hostable, generous free tier (5k replays a month), pricing scales with usage rather than seats. The integrated combo of feature flags + replay is genuinely useful for experiment debugging.

The viewer is good, not great; FullStory and LogRocket still feel more polished. The trade-off is price and the breadth of what you get in one tool.

Best for

Product engineers who want analytics, feature flags, A/B tests, and replay in one open-source stack.

Usero

free, paid from $19/mo

Replay attached to the bug report

The tool I work on, so salt accordingly. Usero records a rolling session buffer in the user’s browser. When they submit feedback through the widget, the last 30 to 60 seconds of activity is attached automatically. The bug report and the replay arrive together, in the same view.

This is a narrower use case than FullStory or LogRocket, deliberately. If you want to watch arbitrary sessions from arbitrary users, pick one of them. If you want every bug report to come with a replay so you stop guessing what the user meant, this is the cheapest way to get there.

Best for

Small teams whose primary use case for replay is “watch what the user did right before they hit the feedback button.”

If You Want To Try Usero

Replay-on-feedback is on the free tier. Drop the widget into a React app in three lines, and the next bug report you get will arrive with a 30-second recording of the exact path the user took. Spin up a widget and see what your real bug reports look like with replay attached.

Frequently Asked Questions