Privacy defaults, not privacy settings

Most session replay tools can be configured to be careful. We built Replayly to be careful before you configure anything. On a new project, input values are masked in the recording and Do Not Track is respected, before anyone opens the settings screen. The point of that default is simple. A missed toggle should not leak a password or an address into a replay a teammate can open later.

The official control list lives in the privacy controls guide. It is also summarized on the fact sheet and the privacy feature page. This post is the practical version: what is always on, what starts on Starter, how to verify the behavior, and how this compares honestly with a tool like Microsoft Clarity.

Why do privacy defaults matter more than privacy settings?

Settings are easy to forget on the second project, on the staging-to-production copy, or on a Friday deploy that grabbed the snippet but not the project config. Session replay reconstructs a page visit. If the visitor typed a password or a home address, a recording that stores those values creates a copy of data they never meant to share with your whole product team.

A default that is off until someone remembers to enable it will, eventually, be left off. So we start with input masking and Do Not Track already on. You can still add stricter controls later. You should not have to remember the first, most important, control at all.

That is also why we talk about defaults in the Microsoft Clarity comparison, rather than claiming to be the only tool that can mask inputs. The useful comparison is which defaults are on for every new project, and whether they stay on.

What does Replayly mask by default?

All input values. Passwords, names typed into forms, and other field values should not appear as plaintext in a recording. That applies to new projects without a configuration change. It is a default, not a reminder on a checklist.

A session replay still records that a field existed and that someone interacted with it. The value is what should not travel with the event stream as readable text. If you need to see whether a visitor stalled on the email field, you can usually see the interaction without reading their address.

Do not assume every sensitive thing on a page lives inside an <input>. A live card preview, a support widget, or a one-time code rendered as ordinary text can still be a problem. That is what block selectors and mask-all-text are for, and those controls start on Starter.

Does Replayly respect Do Not Track by default?

Yes. If a visitor's browser sends that signal, the tracker can stay silent. The install guide documents a test-page escape hatch: append &dnt=0 to the snippet if you need to ignore Do Not Track on a test page. That is an explicit opt-out for debugging. It is not the default for production.

Do Not Track is also not a complete privacy program by itself. Some browsers have limited or changed how they send the signal, and a legal basis for recording may still require consent in your region. Treat DNT as one conservative default, then add consent mode where your policy requires an explicit agreement before recording starts.

Which privacy controls start on Starter and above?

Mask-all-text, CSS block selectors, and consent mode. They sit on top of the defaults that are already on for every plan, including Free.

• Mask all visible text content when you need the replay to show layout and movement without readable copy.
• Block nodes that match CSS selectors. A chat widget, a sidebar, or a live payment preview are typical examples.
• Consent mode: the tracker waits until your site calls window.replayly('consent') after the visitor agrees.

The install guide also documents two CSS classes you can put on markup: rr-block hides a node, and rr-mask masks text. Settings live per project, because a marketing site and a logged-in app rarely share the same risk.

Filters, which help you find sessions with rage clicks, dead clicks, or console errors, also start on Starter. They are not a privacy control. They do reduce the urge to browse recordings at random.

How should you verify masking before production?

Do it on a staging site, with a real form, before the snippet ever reaches a production checkout or account area. A documentation claim is not a substitute for opening a replay and looking.

A short procedure:

1. Create a project and paste the snippet on a staging page that includes form fields.
2. Use Verify installation on the project page so you know events are arriving.
3. Submit obvious test values. A fake password, a fake email, a fake address.
4. Open the recording and confirm those values are not readable.
5. If you will use consent mode, confirm that no recording starts until window.replayly('consent') runs.
6. If you will block selectors, add them and confirm the blocked node is absent from the replay.
7. Only then install on production.

If something is visible that should not be, stop the production rollout. Fix the selector list or the mask settings first. Heatmaps on Pro and Business are generated from the same recordings, so a leak in replay is also a leak in the aggregate view. Read the heatmap feature notes before you enable the tracker on a sensitive flow.

How does this compare with Microsoft Clarity and other tools?

It only compares fairly if you read their current docs, instead of assuming they leave forms unmasked. Clarity's masking documentation, checked on 13 November 2026, says sensitive content is masked by default, the default mode is Balanced, and content in input boxes is masked in all modes and cannot be customized. Clarity also offers Strict and Relaxed modes.

"Replayly masks inputs, Clarity does not" would be a false claim. The useful differences are elsewhere. We respect Do Not Track by default. We document consent mode and selector blocking as Starter features. Clarity is a free Microsoft-hosted product whose data, according to its privacy page, is stored in US data centers. For a full product comparison, see Replayly vs Microsoft Clarity.

When you evaluate Hotjar, PostHog, or anyone else, open their current privacy documentation. Packaging changes, especially after the Contentsquare acquisition of Hotjar. We are not going to invent their default states.

What is Replayly's GDPR and ePrivacy posture?

The product gives you controls. Your organization remains responsible for how you use them. If you use a hosted workspace, we process session data to provide the service. Your team should decide a lawful basis, use consent mode where it is required, keep masking on, and set retention that matches your policy.

Retention is part of that posture. We keep recordings for 7 days on Free, 30 days on Starter, 90 days on Pro, and 365 days on Business, per the pricing catalog. Longer is not automatically better. If you do not need a year of sessions, do not buy a year of sessions.

This page, the privacy policy, and the GDPR session recording checklist are product documentation and a practical list. They are not legal advice. If you need a determination about a specific lawful basis, talk to your counsel.

For the product introduction that sits next to this post, see Introducing Replayly. For plans and current limits, the fact sheet is the page to cite.

Sources

• Replayly privacy controls, facts, install guide, privacy feature page, and the GDPR checklist, checked 13 November 2026.
• Clarity masking and Clarity privacy, checked 13 November 2026, used only for a fair competitor comparison.