How session replay privacy masking keeps you GDPR and CCPA compliant

Done right, session replay privacy masking is what separates a compliant recording tool from a data-protection liability, and it is the first thing a careful buyer asks about before a single session is stored.

The objection is reasonable. A replay reconstructs what a real person saw and typed. Without controls, that can include an email address, a card number, a home address, or a health detail. GDPR and CCPA do not ban session replay, but they do treat that reconstruction as personal data, which means it has to be minimized, secured, retained for a limited time, and in many cases covered by consent.

The good news is that the whole risk collapses when you handle it at the right layer. If the sensitive value never leaves the visitor's browser, there is nothing on your servers to leak, subpoena, or over-retain.

Mask before capture, not after

There are two fundamentally different moments where masking can happen, and only one of them actually protects the user.

Mask before capture runs in the visitor's browser. The recorder walks the page, replaces sensitive text and input values with placeholder characters, and only the masked version is serialized and sent. The raw value is never transmitted. PostHog documents this directly: its privacy controls "run in the browser or mobile app," so "masked data is never sent over the network." Microsoft Clarity states the same principle, that it "never captures anything that is masked or sent over the wire."

Mask after capture records the real values, ships them to a server, and blurs or redacts them at playback time. The unmasked data still crossed the network and still landed in a database. If that store is breached, a redaction rule in the player does nothing.

For a compliance conversation, the distinction is the whole argument. Data minimization under GDPR Article 5 is about not collecting the data, not about hiding it later.

	Mask before capture	Mask after capture
Where masking runs	Visitor's browser	Vendor's server or player
Does raw PII leave the device	No	Yes
What a breach exposes	Placeholders only	Real values
Aligns with data minimization	Yes	Weakly
Retroactive rule changes	Not needed	Needed, and cannot fix past data

The four controls that actually cover you

Input redaction by default

Every serious tool masks form inputs out of the box, because that is where passwords, card numbers, and emails live. In PostHog, all inputs are masked by default and password fields are always masked regardless of configuration. In Clarity, input boxes and drop-downs are masked in every mode, including the most permissive one. Treat any tool that ships with inputs visible by default as a red flag.

Element and text masking

Sensitive data also appears outside form fields: an order confirmation, an account balance, a patient name in a heading. You mask these with CSS selectors or a data attribute on the element, which cascades to its children. PostHog uses classes like ph-no-capture; Clarity uses data-clarity-mask. The safest posture for a high-sensitivity app is to mask everything and selectively unmask only the elements you have confirmed are safe.

Page and route exclusion

Some screens should never be recorded at all, such as a checkout step, a bank-details form, or an authentication screen rendered by a third party. Stopping and starting the recorder around those routes removes the entire screen from capture rather than trying to mask it field by field.

Retention limits

Compliant retention means recordings expire on a defined schedule instead of living forever. Shorter retention shrinks both your breach surface and your obligations when a user exercises a deletion right. Set it to the shortest window that still answers your product questions.

Consent, IPs, and cookies

Whether you need an explicit opt-in depends on jurisdiction and on what you store. Two design choices reduce the burden dramatically:

• No cookies. A recorder that does not set identifying cookies avoids the classic ePrivacy consent trigger for non-essential cookies.
• No stored IP addresses. IP addresses are personal data under GDPR. A tool that discards them at ingestion instead of storing them removes one of the most common raw identifiers from your database.

Even with those in place, treat consent as a legal question for your team, not a checkbox a vendor can answer for you. What a vendor can do is make the compliant path the default so consent covers less sensitive ground.

Sub-processors and where data lives

Masking protects the content of a recording. It does not answer where that recording is stored or who else can touch it. Before you commit, confirm three things: the list of sub-processors the vendor uses, the region where session data is hosted, and whether a Data Processing Agreement is available. A privacy-first replay story falls apart if the data quietly flows to a dozen undisclosed third parties.

How Flowsery approaches this

Flowsery is built privacy-first rather than privacy-optional. Masking is on by default, so sensitive text and inputs are replaced in the browser before anything is serialized. Flowsery is cookie-free and does not store visitor IP addresses, which removes two of the most common identifiers before they ever reach a server. You keep granular control to exclude specific elements and routes and to bound how long recordings are kept.

The result is a replay you can defend in a security review: the sensitive value stays on the visitor's device, and what you store is already minimized.

Frequently asked questions

Is session replay GDPR compliant?

It can be. GDPR does not prohibit session replay, but it treats the recording as personal data. You stay compliant by minimizing what you capture, masking PII before it leaves the browser, limiting retention, securing access, and collecting consent where your jurisdiction requires it.

Does masking after capture satisfy CCPA and GDPR?

It is weaker. If real values reach the vendor's servers and are only hidden at playback, the raw data was still collected and stored, which undercuts data minimization and leaves that data exposed in a breach. Masking before capture is the stronger position.

What gets masked automatically?

In privacy-first tools, form inputs are masked by default and password fields are always masked. Free text, headings, and images that may contain personal data are masked through CSS selectors, a data attribute, or a global mask-everything setting.

Do I still need a consent banner?

It depends on your jurisdiction and what you store. A cookie-free recorder that does not retain IP addresses reduces the triggers, but consent is a legal determination. Confirm your obligations with your own counsel or privacy team.

Can I change masking rules retroactively?

No. Masking is applied at capture time, so a rule change only affects new recordings. Anything already captured keeps whatever masking was in effect then, which is another reason to start strict and loosen deliberately.

Record sessions without recording PII with Flowsery - masking on by default, cookie-free, and no stored IPs.

Sources: PostHog session replay privacy controls and Microsoft Clarity masking content. Checked July 24, 2026.