Session replay and GDPR: what actually needs consent

Session replay has a compliance reputation problem, and most of it is deserved. A tool that records what people do on your site, keystroke by keystroke, is doing something that European law has opinions about.

The confusion comes from conflating two separate legal questions that happen to arrive at the same time. Getting them apart is most of the work.

This is a practical explanation, not legal advice. The rules differ by jurisdiction and the details of your setup matter. If session replay is load-bearing for your business, have someone qualified review it.

Two laws, not one

The ePrivacy Directive — the “cookie law” — governs storing information on, or accessing information from, a user’s device. Article 5(3). This is where cookie banners come from.

GDPR governs processing personal data, wherever it came from.

These are independent. You can trigger one without the other. Most bad advice about session replay comes from treating them as the same rule.

The part almost everyone gets wrong

Article 5(3) is not about cookies. It is about storage on terminal equipment. The word “cookie” does not define the scope — the technology is irrelevant.

That means localStorage, sessionStorage, IndexedDB, and cache-based identifiers are all in scope, and so is device fingerprinting, which stores nothing at all but accesses information from the device. The European Data Protection Board has been explicit about this.

So “we don’t use cookies” is not, by itself, an answer to the consent question. It is an answer to a narrower question than most vendors imply when they say it.

There is an exemption: storage that is “strictly necessary” for a service the user explicitly requested. A shopping cart qualifies. Analytics and session replay generally do not, because the user did not ask to be recorded.

Where session replay actually sits

Being straight about our own tool, since the alternative is asking you to trust a marketing claim.

UserTapes uses no cookies and does no fingerprinting. It stores one thing on the device: a session id in sessionStorage, so that navigating between pages in the same tab stitches into one recording rather than fragmenting into five. That entry is per-tab and disappears when the tab closes. Nothing is written to disk, nothing persists across visits, and there is no identifier that can link today’s session to next week’s.

That is meaningfully different from a persistent cookie. It is not nothing. It is still storage on terminal equipment, and an honest reading of Article 5(3) is that it is in scope.

What that changes in practice is the risk profile, not the legal category. A persistent, cross-visit identifier is what makes tracking a privacy problem worth regulating. A per-tab id that evaporates when the tab closes cannot build a profile, cannot follow someone across sites, and cannot be joined to anything later. Several regulators have signalled that strictly-scoped, non-persistent, first-party measurement is a lower-priority concern than cross-site tracking — but “lower priority” is not “exempt”, and your own DPA may see it differently.

If you want a definitive answer for your jurisdiction, get one. What we will not do is tell you a banner is definitely unnecessary, because we do not know your circumstances and nobody selling you software does.

The GDPR half, which matters more

Even with the storage question settled, GDPR applies independently if you are processing personal data — and session recordings usually are. Behavioural data tied to a session, combined with an IP address, is generally personal data.

This is the half people skip, and it is the half with the larger fines.

What makes replay risky under GDPR

The genuine danger in session replay is capturing what people type. Not their clicks — their content. A tool that records raw input values will, eventually and without anyone intending it, record:

• Passwords typed into a field that was not marked as a password
• Card numbers in a payment form
• Health information in a support message
• Someone’s home address in a shipping form

Once that is in your recording store, you are processing special-category data you never meant to collect, in a system that was not designed to hold it.

This is not hypothetical. It is the most common way session replay turns into an incident.

What actually mitigates it

Mask inputs at the source. The distinction that matters is where masking happens. Server-side redaction means the raw values crossed the network and touched your vendor’s infrastructure before being removed. Masking at record time means the values never leave the browser at all.

UserTapes masks every input in the browser before anything is transmitted. What gets recorded is that a field was filled, never the value — not for payment fields, not for anything, with no allowlist to misconfigure. The transcript line reads typed in a field (value masked at source).

The trade is real and worth stating: if a bug depends on the exact string someone typed, you will not be able to see it. We think that is the correct default. Tools that let you selectively unmask are more useful for debugging and strictly more dangerous.

Mask sensitive text, too. Input values are the obvious risk; rendered text is the quiet one. An order confirmation page displays a full name and address in ordinary DOM text. UserTapes supports a ut-mask class to mask specific text and a ut-block class to skip an element entirely — worth applying to account pages, order confirmations, and anything showing another person’s data.

Set a retention window and keep it short. Storage limitation is a GDPR principle, not a nice-to-have. Recordings you cannot justify keeping should expire automatically rather than by someone remembering to delete them.

Do not record canvas by default. Canvas capture is where medical imaging, signatures, and document previews live.

Know where the data is stored and have a data processing agreement with your vendor.

A practical checklist

Whatever tool you use:

1. Confirm inputs are masked at record time, in the browser, not after upload.
2. Mask or block rendered text that shows personal data — order confirmations, account pages, support threads.
3. Set the shortest retention window you can live with.
4. Document what you record and why, in your privacy policy, in language a person can follow.
5. Decide your consent position deliberately — with advice, if the answer is not obvious — rather than inheriting a vendor’s marketing claim.
6. Check what happens on data subject requests. If someone asks for erasure, can you find and delete their sessions?

Point 5 is the one to actually think about. Plenty of vendors will tell you their tool needs no banner. Whether that is true depends on facts about your site, your jurisdiction, and your regulator — not on their homepage.

Why cookieless is still worth having

None of the above means cookieless is a gimmick. It removes the persistent cross-visit identifier, which is the single thing that turns measurement into tracking. It means there is no profile to leak, no identifier to join against another dataset, and nothing that survives the tab closing.

It makes the consent question easier and the privacy risk genuinely smaller. It does not make either disappear, and you should be suspicious of anyone who says otherwise — including us, if we ever put it that simply.

---

If you want to see how this works in practice, UserTapes records 100 sessions free with no card, cookieless and with inputs masked at the source on every plan. Related: session replay for developers.