Session replay tools like FullStory, Hotjar, and LogRocket are common on commercial websites. The sales pitch is innocent enough: record user sessions to understand pain points, identify usability issues, and improve conversion rates. What companies implementing these tools often don’t understand is exactly how much data they’re capturing and where it goes.

Recent analysis of popular session replay implementations reveals concerning patterns. Many sites are inadvertently capturing sensitive user inputs, sending data to third-party servers without adequate security measures, and violating their own privacy policies in the process.

What Session Replay Actually Captures

The basic functionality is exactly what it sounds like—the script records everything a user does on your site. Mouse movements, clicks, scrolls, form inputs, and page content get captured and sent to the replay provider’s servers.

The replay isn’t a video. It’s a detailed log of DOM changes and user interactions that can be reconstructed into a pixel-perfect recreation of the user’s session. In many ways, this is more privacy-invasive than video because it captures the actual data being entered, not just what appears on screen.

Most replay tools claim to automatically redact sensitive information like credit card numbers, passwords, and social security numbers. The implementation quality of this redaction varies dramatically. Some tools do it well. Others have gaps that allow sensitive data to leak through.

The Masking Problem

Session replay vendors provide various masking options—don’t capture password fields, mask credit card inputs, redact certain form fields. But these protections only work if developers properly configure them.

Default configurations often capture everything. Developers need to explicitly mark fields as sensitive or configure global masking rules. On many sites, this configuration never happens or is incomplete.

I’ve seen implementations where password fields were masked but password reset security questions weren’t. Email addresses were captured when they shouldn’t have been. Private messages on messaging platforms were recorded in full because developers didn’t realize the replay script was active on those pages.

The responsibility falls on the site implementing the tool, but most developers don’t fully understand what data the script collects or how to properly configure privacy protections.

Third-Party Data Transmission

Every interaction captured by session replay scripts gets transmitted to the vendor’s servers. You’re not just allowing the website owner to see your activity—you’re allowing a third-party service to collect detailed logs of your behavior.

What does that third party do with the data? Their privacy policies typically allow broad data usage rights. The data might be used for product improvement, shared with analytics partners, or retained indefinitely.

If the session replay vendor experiences a data breach, your interaction data from dozens of websites could be exposed simultaneously. Most users have no idea which sites they visit use session replay tools, much less which vendors those sites have chosen.

GDPR and Consent Requirements

Under GDPR, session replay likely requires explicit user consent because it involves processing detailed personal data. The data collected can often identify individuals and track behavior across sessions.

Many sites using session replay don’t obtain proper consent. They treat it like standard analytics rather than the extensive monitoring it actually is. Privacy policies mention “analytics tools” without specifying session replay or explaining the extent of data collection.

The legal exposure for sites using these tools without proper consent is significant. Regulators have been slow to focus on session replay specifically, but that’s changing as awareness grows about what these tools actually capture.

Healthcare and Financial Site Usage

The most alarming implementations are on healthcare and financial services sites. These sites handle highly sensitive information, and session replay on patient portals or banking interfaces can capture medical details, financial data, and account information.

HIPAA and PCI-DSS have specific requirements about third-party data processing and security controls. Session replay implementations that transmit unmasked sensitive data to vendor servers likely violate those requirements.

Some healthcare systems have implemented session replay on patient portals where users view test results, medication lists, and medical histories. If that data is being replayed and stored by third parties, it’s a compliance nightmare.

Mobile App Session Replay

Mobile apps increasingly include session replay SDKs with similar functionality to web-based tools. The privacy implications are worse because mobile apps typically have access to more sensitive data and device sensors.

Mobile session replay can capture app UI state, user inputs, and depending on SDK permissions, potentially location data, device identifiers, and information from other apps. The lack of transparency about what’s being captured is even worse than on web.

Users can block web-based session replay with browser extensions. On mobile apps, there’s no equivalent user control. You either use the app with session replay active or don’t use it at all.

The Business Justification Is Weak

Companies implement session replay to identify usability problems and improve conversion rates. But traditional analytics combined with targeted user testing usually provides similar insights without the privacy invasion.

Watching recordings of thousands of user sessions is time-consuming. Most session replay customers record everything but only review a tiny fraction of sessions. The vast majority of captured data is never looked at—it just sits on servers creating liability.

The conversion improvements from session replay are often modest and could be achieved through less invasive methods. A/B testing, funnel analysis, and direct user feedback provide actionable insights without recording every keystroke.

What Users Can Do

Browser extensions like uBlock Origin and Privacy Badger can block session replay scripts. Content Security Policy directives can prevent script loading if you control the browser environment.

Checking a site’s source code for common session replay vendor scripts (FullStory, Hotjar, LogRocket, etc.) tells you if replay is active. If you see those scripts and the site handles sensitive data, that’s a red flag.

Using form autocomplete from password managers rather than manually typing reduces what gets captured. Passwords filled by browser extensions often don’t trigger the same JavaScript events as manual typing.

For truly sensitive sites, using dedicated browsing sessions or incognito mode prevents session replay from linking behavior across visits through persistent identifiers.

What Developers Should Do

If you’re implementing session replay, audit exactly what’s being captured. Test with real workflows including sensitive operations. Check what data appears in replay logs on the vendor dashboard.

Configure comprehensive field masking for any sensitive inputs. Don’t rely on default configurations—they’re not privacy-protective enough.

Disclose session replay in privacy policies with actual specifics. “We use analytics tools” doesn’t cut it. “We record your sessions including mouse movements and interactions using FullStory” is honest.

Question whether you actually need session replay. If you’re using it but not regularly reviewing sessions or acting on insights, you’re creating privacy liability without corresponding benefit.

The Regulatory Future

Expect increased scrutiny of session replay from privacy regulators. As awareness grows about what these tools capture, expect GDPR fines for sites that don’t obtain proper consent or that capture sensitive data inappropriately.

California’s CPRA and other privacy laws will likely evolve to address session replay specifically. The current legal framework treats it like standard analytics, but the data collection is fundamentally different in scope and sensitivity.

Vendors will face pressure to improve default privacy protections. The current model of requiring developers to configure masking creates too many opportunities for sensitive data to leak. Better default configurations that capture less by default would help.

The Honest Assessment

Session replay provides value for optimizing user experience. But the privacy costs are higher than most people realize, and the security risks from extensive third-party data collection are significant.

If you’re a user, assume that sites you visit may be recording your sessions. Adjust behavior accordingly on sensitive sites. Use privacy tools to block session replay when possible.

If you’re implementing these tools, be honest about the tradeoffs. The conversion improvements probably don’t justify the privacy invasion on sites handling sensitive user data. For general commercial sites, the calculation might be different, but you still need proper consent and masking.

The session replay industry has operated below the radar of privacy advocates and regulators for too long. As awareness grows, expect changes—either through regulation forcing better practices or through privacy backlash as users realize the extent of monitoring.