Session replay: what it records, and who’s sued over it?

Session replay is a digital analytics technology that records what a visitor does on a website (clicks, scrolls, form entries, including text never submitted) and rebuilds it as a playable session. It is not a screen recording. The tool captures page events and re-renders them later, which is why it can capture more than you intended.

In June 2023, a group of Kaiser Permanente patients filed a federal lawsuit against the health plan. The complaint alleged that the health plan had embedded Quantum Metric’s “Session Replay” code not only on its public homepage but also in the logged-in patient portal, where it intercepted form entries and messages to doctors about diagnoses, symptoms, and payment information in real time as they were in transit.

By April 2024, Kaiser had notified about 13.4 million members of the data disclosure. In December 2025, it agreed to a $46 million settlement (capped at $47.5 million) covering about 13 million people across eight states and D.C. The court granted final approval on July 22, 2026. Kaiser denies all allegations. The settlement admits nothing.

This article is for DPOs, privacy counsel, or product leads who need to answer, “Is our replay tool legal?” Here’s what session replay records, what the law says, and how you can check what your tool sends.

What is session replay?

Session replay is a class of analytics tooling that logs a visitor’s interactions with a page as structured events: every click, scroll, mouse movement, keystroke, and field entry. It reconstructs a user session from user actions and presents it in a video like playback.

Vendors also sell it as “session recording”. The terms are interchangeable. A “session” (one continuous visit) is distinct from a “view” (a single page within it).

A session replay tool does not record pixels. It watches the page’s document object model (the live structure of the page in the browser), logs every mutation and input event, and re-renders them against a cached copy of the page’s layout and styles. That is how session replay works.

That’s why replays can sometimes look wrong: if your site’s CSS or layout changes between recording and playback, the replay may not match exactly. It’s a re-enactment based on a script, not footage.

This setup has important consequences. Most teams don’t choose it on purpose. Since the tool records events as they happen, it can capture text as visitors type or how users interact with the page, including mouse movements and other user interactions, even if visitors edit or delete text before submitting. The real legal risk is in what gets sent, not just what you see in the playback.

Teams use session replay for good reasons: to reproduce bugs that logs can’t explain, to provide visual evidence for support, and to spot user experience issues that numbers alone don’t reveal. Session replay lets teams understand user behavior in full context and gain a deeper understanding of user journeys.

Who receives a session recording?

The recording leaves the visitor’s browser. It doesn’t sit on your servers either. The replay script transmits the captured events to the vendor’s cloud (FullStory, Hotjar, Quantum Metric, Microsoft Clarity, Glassbox), where the session is stored, indexed, and made playable to your team. To plaintiffs’ lawyers, that transmission is the whole case: a third party received the contents of a communication between the visitor and your website.

Your replay vendor may be a data recipient with its own uses, not a passive tape recorder. The web-tracking guide explains the full chain of who receives client-side data, and how to map it.

Is session replay legal?

Using session replay isn’t illegal. There’s no law that bans the tool, and no court has ruled that replay software is unlawful by itself. The real legal debates are about how it’s deployed: what it captures, which pages it’s on, who it’s for, and whether visitors gave consent before recording started.

The honest answer is not “yes” or “no” but “it depends on facts you can actually check.” The risk is configuration-specific and capture-specific, not tool-specific.

Two companies using the same vendor’s script can end up on different sides of the legal line. What matters is what the tool captured on each page, whether masking happened before data left the browser, and what visitors were told in advance.

Why do plaintiffs call it wiretapping?

Because the technical mechanism described above maps element by element onto a legal theory written for telephone eavesdropping. Wiretap statutes like California’s Invasion of Privacy Act (CIPA) and the federal Electronic Communications Privacy Act (ECPA) prohibit a third party from intercepting the contents of a communication in transit without consent. The theory has three parts, each attached to a specific technical fact about session replay:

• Contents. A keystroke-by-keystroke record of what a visitor typed (search terms, form entries, messages) is the content of a communication, not metadata about it. (Courts have accepted this: replay captures can qualify as “contents,” per Mikulsky v. Bloomingdale’s, below.)
• A third party. The replay vendor’s servers receive the capture, and the vendor is neither the visitor nor the website: an “unannounced second auditor” on the line, in one California federal court’s phrase.
• No prior consent. The script typically loads and begins capturing before any banner is acted on, so even a visitor who eventually clicks “accept” was recorded first.

The defense has its own technical fulcrum. Replay is not a continuous recording like a wiretap. It is an event log that becomes readable only when reassembled later. One federal court accepted this argument in 2025, holding that captured events “do not become readable content until after they are stored and reassembled” and granting summary judgment on the in-transit theory (Torres, below). The same court rejected the tape-recorder defense (the vendor’s “superuser” access to stored sessions defeated the party exception). The fulcrum narrows the theory rather than killing it.

There is also a party exception. A party to a communication cannot “intercept” it, and vendors acting as the website’s mere tool have sometimes been folded into it. The root authority on both the exception and its limit is the California Supreme Court’s 1985 decision in Ribas v. Clark, which distinguished a party recording its own conversation from a third party eavesdropping on someone else’s.

The legal analysis may depend on what the replay vendor is permitted to do with the session data. If the vendor only processes the data on the website’s behalf, it may function more like a service provider. If it can access or use the data for its own purposes, its role may be legally different.

One architectural distinction runs through all of it. Masking at playback is not masking. If the raw keystrokes crossed the wire to the vendor and are only hidden when your team watches the replay, the interception already happened. The masking protects whoever watches, not whoever was recorded.

Only suppression before capture, inside the browser, is a defense-shaped fact. A Ninth Circuit footnote made this outcome-relevant in 2025 (see Popa, below), which is why the verification section tests masking at the payload, not in the replay viewer.

The economics explain the volume. As defense firm Loeb & Loeb put it in May 2026, after the Third Circuit’s replay decision: 

“Privacy class actions under wiretap statutes have become an industrialized revenue stream for the plaintiffs’ bar, and they price their demands against the cost of defense.”

(Loeb & Loeb, May 29, 2026)

Which laws apply, and what does each one cost?

Four statutes, six operative provisions, generate nearly all session-replay claims, each priced differently. The table carries only rows with live replay or tracker case citations; the complete CIPA statute map and exposure math live in the CIPA guide.

The “so what” is the arithmetic: statutory damages accrue per violation with no proof of harm required under CIPA, and a class is every recorded session in the class period. A mid-traffic site running unmasked replay on a login page is not looking at a fine but a multiplication.

It’s important not to confuse CIPA with CCPA. The California Consumer Privacy Act is about notice and opt-out, and it’s enforced by the state. For example, the California Privacy Protection Agency’s 2025 settlement with Tractor Supply ($1.35 million, partly for ignoring Global Privacy Control signals) was under CCPA.

Does this apply outside California?

Yes. The relevant geography is your visitors’, not yours. CIPA claims are brought for visitors located in California, regardless of where your company is located. Pennsylvania’s Wiretapping and Electronic Surveillance Control Act (WESCA) and Florida’s Security of Communications Act (FSCA) do the same for their residents, and the federal ECPA covers interstate communications everywhere.

A company with no California office and California visitors on an authenticated portal is in scope. The multi-state class in the Kaiser settlement (eight states plus D.C., built on Maryland, Georgia, Washington, and District of Columbia statutes alongside California’s) is what that looks like in practice.

Where do the courts stand? The case-law split

There is no circuit consensus and no clean trendline: the split turns on what was captured, when consent happened, and which court is asked. Read the table chronologically.

Three readings matter more than any single row.

• The law is converging on fact-specificity, not on “replay is fine” or “replay is wiretapping”: BPS Direct draws the line at what was captured, Popa at what was masked, Javier at when consent happened.
• Several headline defense wins are pixel or live-chat cases that carry over only by analogy, as labeled. The replay-specific holdings are more mixed than vendor content suggests.
• The standing fight in Popa was decided by the tool’s own configuration. Eric Goldman wrote when the opinion came down that recording for session replay is “a fundamentally inconsequential act by itself”, adding the warning operators should keep: “That’s a warning to any Clarity or other session replay users who aren’t suppressing recording of user text.”

The volume behind the table is documented in court filings, not marketing decks. The Retail Litigation Center’s amicus brief in Variety Media v. Superior Court counts 1,981 § 638.51 cases in California trial courts plus 247 California federal cases from 2023 forward, with over 1,500 businesses targeted between 2022 and April 2025.

The settlement market has already priced the replay-specific version of the theory. The Kaiser case from this article’s opening, the largest U.S. settlement to date whose complaint named a session-replay tool verbatim, closed at $46–47.5 million with final approval in July 2026. Kaiser admitted nothing. It paid anyway.

Does your cookie banner protect you?

Only if it blocks the replay script from capturing before consent. Most don’t. Javier established that CIPA § 631(a) demands prior consent, so a banner that appears while the script is already recording does not create consent. It timestamps the violation.

A privacy policy that discloses replay is weaker still: a footer browsewrap link, a posted policy hyperlink the visitor never affirmatively accepts, is not assent. 

The full anatomy of consent states (what fires before, during, and after interaction) is mapped in the web-tracking guide. For replay, the question is whether anything was captured in the pre-consent window.

The tradeoff is that gating replay behind opt-in consent shrinks your California dataset to the consenting minority. Many visitors never interact with a banner. That is a real cost, and exactly the cost Lakes v. Ubisoft says a defensible deployment pays.

How long does a plaintiff have to sue?

How long a plaintiff has to sue is unsettled. CIPA’s private-action provision, § 637.2, contains no express limitations period, so courts borrow one from analogous California statutes. At the time of writing, no California appellate decision has definitively selected the period for CIPA session replay claims. The live candidates:

• One year (CCP § 340(a)): The plaintiffs’ bar’s least favorite: the period for actions on “a penalty or forfeiture,” which fits § 637.2’s $5,000-per-violation statutory damages.
• Three years (CCP § 338(a)): The period for actions on “a liability created by statute,” which fits the same provision from the other side.
• The discovery rule: Plaintiffs argue the clock starts when they could reasonably have discovered the capture, which for an invisible script can be years after deployment. One federal court applied the discovery rule at the pleading stage to CIPA §§ 632/632.7 claims in Ramos v. Capital One (N.D. Cal. 2017), holding the complaint sufficiently alleged delayed accrual. A single district order is indicative, not settled law, but it is the direction plaintiffs argue.

The federal ECPA track needs no borrowing. 18 U.S.C. § 2520(e) sets two years from the date the claimant had a reasonable opportunity to discover the violation. Either way, the exposure window stretches years behind you.

Did SB 690 change any of this?

Narrowly, and only if signed. Senate Bill 690 passed the California Legislature in late August 2026 and was presented to the Governor in early September. At the time of writing, it is neither signed nor vetoed. Because it arrived at the end of the legislative session, the Governor has until September 30, 2026, to act, and absent a veto, it becomes law without signature.

If enacted, the enrolled text does one thing: private § 638.51 pen-register actions against private actors “may be brought under this section only by the Attorney General,” retroactive to pending claims in actions commenced within two years of the operative date. That would kill the metadata-only branch of the tracker-litigation industry.

What it does not touch is § 631. The contents-interception theory at the heart of every replay case in this article survives SB 690 unchanged. If your exposure comes from replay capturing form entries, SB 690 is not your rescue.

Which pages and fields raise the risk?

Risk follows the sensitivity of what a page collects. It also follows provability: the Third Circuit now asks whether you can show, per page and field, what your deployment captured. Rank your own deployment against this table.

Notice the pattern. None of these rows requires malicious intent or unusual configuration. A default replay deployment on a default website touches at least two of them.

What do session replay tools actually send, and how do you verify them?

Every legal question above (contents, consent, masking, standing) reduces to empirical facts about your own deployment, and every one of those facts is checkable from your own browser.

Don’t rely on vendor assurances as proof. The four checks below give you real evidence. Run them in order, since each step depends on the previous one.

Does capture start before consent?

In most deployments, yes. The script loads and records before the banner is acted on. It is testable from your own browser, in four checks of increasing rigor:

1. The <head> check. View your page source. If the replay snippet is hard-coded in <head> outside your consent manager’s control, it fires for every visitor before any consent event can exist. Configuration, not consent, is governing your deployment.
2. The GTM Preview check. If the script loads through Google Tag Manager, open GTM’s Preview mode on a fresh consent state and look at “Tags Not Fired.” A replay tag in the not-fired list before consent is the compliant posture. A replay tag under “Tags Fired” is your Javier problem, documented by your own tooling.
3. The consent-to-recording lag. Accept the banner, then compare the timestamp of your consent event against the first replay network call in developer tools. A recording that predates the click by seconds, or by an entire pageview, is a capture without prior consent, regardless of what the banner eventually collected.
4. The Global Privacy Control (GPC) propagation test. Visit with GPC enabled and check whether the replay script still loads. Clarity honors GPC. Other vendors’ handling varies, and California’s CPPA has already fined a company (Tractor Supply, in the enforcement action cited above) partly for ignoring the signal.

The generic method behind all four (fresh profile, network tab, watch what fires when) is the pixel self-check.

What does it capture?

Open your vendor’s replay viewer and watch your own sessions: not the aggregate dashboards, the raw playbacks. Then run a scripted test visit: type into every form on your riskiest pages (checkout, login, contact, search), including text you deliberately delete before submitting. What appears in the playback is what a plaintiff’s expert will reconstruct. Three things to look for:

• field values rendering in the playback at all.
• non-submitted text (the draft you deleted) appearing in the recording.
• the search-field pattern: queries visible in the recording, which Heerde treats as “contents”.

For a field-by-field answer, inspect the payload itself. Replay tools transmit captures as event batches to vendor endpoints visible in the network tab. What crosses the wire, not what the viewer shows, is the legal fact because playback masking can hide from you what was already sent.

Is the masking real?

Masking claims are vendor documentation; masking behavior is your deployment. The defaults below are verified against each vendor’s own documentation as of 2026. Re-verify before relying: vendors change defaults silently:

Running a vendor not listed here (Glassbox, Quantum Metric, LogRocket)? The test is identical: defaults are marketing claims. The payload check above is the evidence. Verify what crosses the wire on your deployment rather than trusting any row, including these.

Two traps to test explicitly: 

• “Masked by default” describes inputs, not page content: a Hotjar deployment can faithfully mask every form field while recording the health condition rendered in the page’s own text.
• Masking is configuration: verify the attribute or class is present on your riskiest fields in the deployed markup, not just enabled in a settings screen. The Popa footnote above is the legal weight of this check: masking before capture was outcome-relevant in the Ninth Circuit’s only published replay-standing decision.

Will it still be true after the next release?

Everything you just verified has a shelf life of one deployment. Masking breaks silently when frontend ships. A redesigned checkout loses its data-hj-suppress attributes, a new search component ships outside the exclusion classes, and a tag manager republish changes the firing order. Wire the four checks into release QA. Re-run them on every deploy that touches a page in the risk table above and on a calendar cadence for everything else. Verification is a loop, not a project.

Manual checks only give you an accurate picture for one day. The next release can change everything. Keeping things accurate over time requires ongoing monitoring.

You got a demand letter mentioning session replay. What now?

If you get a demand letter or face a lawsuit, stop and preserve everything before you touch anything (the letter, CMP settings, tag manager export, consent logs, and the policy version in effect at the referenced date). Engage counsel, notify your insurers early, and consider the costs before deciding what to do next.

It’s natural to want to remove the tool right away, but doing so can destroy evidence that might help your case. Always preserve evidence before making changes. Use our full CIPA demand-letter playbook for the right first steps.

This article adds a replay-specific step: check the technical details before you start negotiating. Find out exactly what your tool captured during the time in question. The verification checks above (firing order, payload contents, and masking state as deployed then) turn the letter’s claims from assertions into facts you can confirm.

Some complaints claim data was captured when masking actually prevented it (as in the Popa case), while others may exaggerate or understate what happened. You need to know the facts before you respond.

The session replay risk checklist

1. Gate the load, not just the events. Consent-gating that lets the script load and buffer pre-consent is not prior consent under Javier. The script should not execute for a visitor who hasn’t consented. Verify with the firing checks in the verification section, not with your CMP’s dashboard.
2. Exclude by page and field. Apply the risk table: no capture on checkout, authenticated, or health- and finance-adjacent pages unless you have a documented reason. Apply field-level exclusions on free-text inputs everywhere else.
3. Verify masking at the payload. Named attributes present in deployed markup, tested after the last release, not assumed from a settings screen.
4. Set a retention floor. Keep sessions only as long as the stated use requires. Every retained session is discoverable, and CNIL’s draft framework (below) gives the emerging benchmark: hours for support use, months for UX analysis. Retention schedules as a discipline are covered in the data-retention guide.
5. Ask the vendor-as-agent question in the contract. Whether your vendor is your tape recorder or an eavesdropper turns on the access and use rights its terms grant: the Torres “superuser” problem and Clarity’s independent-controller terms are the two ends of that spectrum. If the contract gives the vendor its own uses for the data, that is a legal fact about your deployment.
6. Minimize the footprint. Don’t record pages nobody analyzes. Every recorded session is liability inventory. Sampling and trigger-based capture (record the checkout-abandonment flow, not the whole site) shrinks both the class and the discovery surface.

What about mobile apps and session replay?

Mobile session replay is a different mechanism with its own risk surface. Instead of logging DOM events in a browser, mobile SDKs capture the app’s rendered screens (closer to actual screen recording) along with taps, swipes, and gestures. The wiretap logic above transfers. The capture surface, masking techniques, and SDK behavior are distinct and have their own treatment.

Complete guide to mobile session replay → 

How MELURNA helps with session replay risk

The four checks in the verification section are manual: run them once and get a snapshot for that day. MELURNA is designed for ongoing monitoring. It continuously tracks what client-side scripts do in the browser, continuously and across releases, which makes it the always-on version of that checklist.

• Firing order. Which scripts loaded before consent, on which pages, watched continuously rather than spot-checked before a letter forces the question.
• Payload contents. What data each script sends and where it goes, observed rather than assumed: the contents-versus-metadata line your exposure turns on.
• Masking drift. When a release changes what leaves the page (a redesigned checkout that drops its suppression attributes), the change shows up in what you send, not in a settings screen.
• Evidence over time. A before-and-after history of what your site transmitted, kept audit-ready: the same class of proof the demand-letter section tells you to preserve.

See it on your own site →

FAQs

DISCLAIMER: This guide is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.