GDPR-Compliant Session Recording: How to Record User Sessions Without Violating Privacy

Session recordings are one of the most powerful tools in a product team's arsenal. Watching real users navigate your interface reveals friction points, confusing layouts, and broken flows that no amount of analytics dashboards can match. But there is a catch: session recordings are a GDPR minefield.

Every keystroke, every form field, every piece of text visible on screen is potentially captured. Without careful implementation, you could be recording email addresses, phone numbers, credit card details, and other personally identifiable information (PII) — and storing it without proper legal basis.

This guide explains exactly what GDPR requires for session recording, how modern privacy-first tools handle PII masking, and what you need to do to stay compliant while still getting the insights you need.

Why Session Recordings Are a Privacy Risk

Session recording works by capturing a stream of DOM mutations, user inputs, mouse movements, and scroll events on a webpage. This data is then reconstructed into a video-like replay that shows exactly what the user saw and did. The problem is that this reconstruction is pixel-perfect — it captures everything.

Here is what can end up in your session recordings without proper safeguards:

• Form input data — Names, email addresses, phone numbers, postal addresses, passwords, credit card numbers, social security numbers
• Sensitive content on screen — Medical information in patient portals, financial details in banking apps, legal documents, private messages
• URL parameters — Email addresses in reset links, user IDs in URL paths, search queries containing personal information
• Third-party embeds — Chat widgets showing conversation history, support tickets with personal details, social media widgets with user names

Under GDPR, all of this constitutes personal data. Collecting it without a valid legal basis, failing to inform users, or storing it longer than necessary can result in fines of up to 4% of annual global turnover or 20 million euros, whichever is higher.

In 2023, the French data protection authority (CNIL) fined Criteo 40 million euros for privacy violations related to user tracking. Session recording tools that capture PII without consent face similar regulatory exposure.

GDPR Requirements for Session Replay

The General Data Protection Regulation does not specifically mention "session recording" or "session replay." But it does regulate the processing of personal data — and session recordings that capture PII are squarely within its scope. Here are the key requirements:

Legal Basis for Processing

You need one of six legal bases under GDPR Article 6 to process personal data. For session recording, the two most relevant are:

• Consent (Article 6(1)(a)) — The user has given explicit, informed consent for their session to be recorded. This requires a clear opt-in mechanism (not a pre-checked box).
• Legitimate Interest (Article 6(1)(f)) — You have a legitimate business interest in recording sessions (improving UX), and this interest is not overridden by the user's rights and freedoms. This argument is much stronger if you mask all PII — because if no personal data is captured, the privacy impact is minimal.

Data Minimization (Article 5(1)(c))

GDPR requires that personal data be "adequate, relevant, and limited to what is necessary." This means you should only capture the data you actually need. Recording every keystroke in a credit card field is not necessary for UX analysis. Masking it still gives you the insight that a user filled in the field, without capturing the sensitive content.

Purpose Limitation (Article 5(1)(b))

Data must be collected for specified, explicit, and legitimate purposes. Session recordings collected for UX improvement cannot be repurposed for marketing profiling without a separate legal basis.

Data Retention (Article 5(1)(e))

Personal data must not be kept longer than necessary. Many privacy-first session recording tools enforce automatic deletion after 30 or 90 days. If your tool does not do this, you need a manual retention policy.

Data Subject Rights

Users have the right to access, rectify, and delete their personal data. If a user requests deletion of their session recordings, you must be able to identify and remove them. This requires tools that can link recordings to individual users — or better yet, tools that never capture identifying data in the first place.

How PII Masking Works

PII masking is the technical mechanism that prevents personal data from being captured in session recordings. There are two main approaches:

Allowlist Approach (Recommended)

This is the most privacy-secure method. By default, all text input is masked. Only fields that you explicitly allowlist are recorded with their actual content. Typical allowlist candidates:

• Search bars (users search for products or content, not personal data)
• Filter dropdowns (e.g., "Sort by price")
• Non-sensitive navigation inputs

Everything else — name fields, email fields, address fields, password fields, textarea inputs — is automatically replaced with placeholder characters in the recording. The user's interaction with the field (click, focus, typing activity) is still visible, but the actual content is never captured.

Blocklist Approach (Traditional)

Older tools use a blocklist approach: by default, everything is recorded, and you must manually specify which fields to mask. This is risky because:

• It is easy to miss a field — a new form gets added, nobody updates the blocklist, and PII leaks into recordings
• Some fields are ambiguous — is a "company name" field personal data? It depends on the context
• The burden is on you to maintain the blocklist as your application evolves

Privacy-first tools like RevKlik use the allowlist approach because it is fail-safe: if you forget to configure something, the worst case is that search queries are masked (a minor loss of insight), not that credit card numbers are exposed (a major breach).

How Masking Looks in Practice

When you watch a session recording with PII masking enabled, form fields appear with generic content instead of the user's actual input:

• A name field shows *** instead of "Jane Doe"
• An email field shows *****@***.*** instead of "jane@example.com"
• A phone field shows ***-***-**** instead of "555-0123"

The masking happens client-side, before data leaves the browser. The recording server never receives the unmasked content. This is a critical distinction — server-side masking (where the full data is sent and then stripped) does not provide the same protection because the data has already traversed the network and been stored, even briefly.

Session Replay Tools: Privacy Comparison

Feature	RevKlik	Hotjar	FullStory	PostHog
PII Masking Default	All fields masked	Requires config	Partial auto	Requires config
Masking Approach	Allowlist	Blocklist	Hybrid	Blocklist
Cookieless	Yes	No	No	Optional
Consent Required	No (no PII captured)	Yes	Yes	Varies
Cross-Site Tracking	No	Yes	Yes	Optional
Script Size	<1 KB	~50 KB	~80 KB	~45 KB
Data Retention	30 days default	365 days	Custom	Self-managed
Data Residency	EU available	US only	US / EU	Self-hosted option
Revenue Attribution	Native	No	Enterprise only	Requires setup
Pricing (from)	$1/mo	$32/mo	$79/mo	Free tier / $0.031/event

Hotjar

Hotjar is one of the most popular session recording tools, but its privacy model requires careful configuration. By default, Hotjar records all input fields. You must manually define which fields to mask using CSS selectors or HTML attributes. If you add a new form and forget to update the mask list, PII will be captured. Hotjar also sets cookies for cross-session tracking, which requires consent under GDPR and ePR. See our detailed comparison in RevKlik vs Hotjar.

FullStory

FullStory has a more sophisticated privacy model with some automatic PII detection, but it still captures significant data by default. Its cross-site identification capabilities (linking a user's behavior across multiple websites) are powerful for analytics but represent a privacy concern. FullStory is also US-headquartered, which means data is subject to US surveillance laws — a consideration for EU businesses under the Schrems II ruling.

PostHog

PostHog offers self-hosting, which gives you full control over data residency — a significant advantage for GDPR compliance. However, PII masking still requires manual configuration, and the default recording mode captures form inputs. The self-hosted option means compliance responsibility falls entirely on you: retention policies, access controls, and encryption are all in your hands.

RevKlik

RevKlik takes a fundamentally different approach: privacy by default, not privacy by configuration. All text input is masked before it leaves the browser. No cookies are set. No cross-site identification occurs. The recording script is under 1KB — compared to 50-80KB for competitors — so it does not slow down your site or trigger ad blockers. Revenue attribution is built in natively, so you can connect session behavior to actual purchases. See our best cookieless analytics tools guide for a broader comparison.

Implementation Best Practices

Whether you use RevKlik or another tool, follow these practices to ensure your session recordings are GDPR-compliant:

1. Mask All Input by Default

Start from the assumption that every form field contains personal data. Only allowlist fields where you are certain the content is not personal — search bars, product filters, quantity selectors. This is the opposite of the traditional approach (record everything, then exclude sensitive fields), but it is far safer.

2. Mask Sensitive URLs and Text Content

PII does not only appear in form fields. It can also be present in:

• URL paths — /user/jane@example.com/settings
• URL parameters — ?email=jane@example.com&token=abc123
• Visible text on page — A greeting like "Welcome back, Jane" in a dashboard header
• Third-party widget content — Chat windows, support tickets, social media embeds

Configure your recording tool to mask or redact these elements as well. RevKlik handles this automatically by masking all text nodes inside specified DOM regions.

3. Implement Proper Consent Management

If your recording tool captures any personal data (even with masking, some tools still process data server-side), you need a consent mechanism. Requirements:

• Clear and specific — "We record user sessions to improve our product" is not enough. Explain what data is captured and why.
• Opt-in, not opt-out — The default must be "not recording." Users must actively consent.
• Easy to withdraw — Provide a clear way to opt out at any time, without requiring account creation or complex steps.

If you use RevKlik with all PII masked and no cookies, the consent requirement is significantly reduced because you are not processing personal data. But transparency is still best practice — let users know that anonymous session recordings are collected for UX improvement.

4. Enforce Data Retention Limits

Do not keep session recordings indefinitely. Set a retention period based on your actual need:

• 7-14 days — Sufficient for weekly UX review cycles
• 30 days — Good balance for most teams (RevKlik default)
• 90 days — Maximum recommended for most use cases

Automate deletion. Manual retention policies are forgotten when the person responsible moves on to another role.

5. Restrict Internal Access

Not everyone in your organization needs access to session recordings. Limit access to the team members who actually analyze UX — typically product managers, designers, and frontend developers. Implement role-based access controls and log who views which recordings.

6. Document Your Processing

Under GDPR Article 30, you must maintain a Record of Processing Activities (ROPA) that includes session recording. Document:

• What data is captured in recordings
• The legal basis for recording
• How PII is masked
• How long recordings are retained
• Who has access to recordings
• How users can exercise their data subject rights

The Privacy-First Path Forward

Session recording does not have to be a privacy compromise. The most useful insights from session replay are behavioral — where users click, how far they scroll, where they hesitate, where they abandon a flow. None of these insights require capturing what a user typed into an email field or what their phone number is.

Privacy-first tools like RevKlik prove that you can get the full value of session recording without the legal risk. By masking all PII at the source (in the browser, before data is transmitted), operating without cookies, and avoiding cross-site identification, these tools deliver the behavioral insights product teams need while respecting user privacy by design.

The result is a win for everyone: your team gets the UX insights they need, your users get their privacy respected, and your legal team does not have to worry about GDPR enforcement actions.

FAQ

Is session recording GDPR compliant?

Session recording can be GDPR compliant, but it requires careful implementation. The tool must automatically mask personally identifiable information in form fields, avoid using tracking cookies without consent, process data within the EU or under adequate safeguards, and provide users with opt-out capability. Privacy-first tools like RevKlik are designed with these requirements built in by default, making compliance straightforward.

What PII is captured in session recordings?

Without proper masking, session recordings can capture names, email addresses, phone numbers, credit card numbers, passwords, postal addresses, and any other information users type into form fields. They may also capture sensitive data visible on screen such as medical information or financial details. This is why automatic PII masking — applied before data leaves the browser — is essential.

Do I need consent for session recording under GDPR?

If the recording captures any personal data, you generally need either explicit consent or a legitimate interest basis. Tools that mask all PII and operate cookieless have a stronger legitimate interest argument because the privacy impact is minimal. However, the specific requirements depend on your jurisdiction and use case. Always consult a legal professional.

How does PII masking work in session replay?

PII masking intercepts text input before it is recorded and replaces it with placeholder characters. Privacy-first tools mask all input fields by default, using an allowlist approach where you explicitly opt in only non-sensitive fields (like search bars). The masking happens client-side in the browser, so sensitive data never reaches the recording server at all.