Microsoft Clarity and GDPR: Consent Needed?

Microsoft Clarity is a genuinely useful tool. It gives a small business session recordings, heatmaps, rage-click and dead-click detection, the kind of insight that used to require an expensive analytics stack. That is exactly why it is on so many small sites, and why the question “is Microsoft Clarity GDPR compliant?” keeps coming up.

The short answer: Clarity can be used lawfully, but not by pasting the snippet and forgetting about it. It needs prior consent from European visitors, and since late 2025 Microsoft enforces that itself.

What Clarity stores on your visitors’ devices

Microsoft publishes the list of cookies Clarity sets:

Cookie	Party	What Microsoft says it does
_clck	First-party	Persists the Clarity user ID and preferences for your site
_clsk	First-party	Connects several page views into a single session recording
CLID	Third-party	Identifies the first time Clarity saw this user on any site using Clarity
ANONCHK	Third-party	Flag on whether MUID is transferred to ANID (Clarity says it does not use ANID)
MR	Third-party	Indicates whether to refresh MUID
MUID	Third-party	Identifies unique browsers visiting Microsoft sites, used for advertising, site analytics and other operational purposes
SM	Third-party	Synchronises MUID across Microsoft domains

The last rows matter most. MUID is a Microsoft-wide identifier, not something scoped to your site. That rules out the consent exemption some regulators allow for audience measurement: the French CNIL’s conditions for exempt analytics require, among other things, that the tracker is limited to a single publisher and that the data is not cross-checked with other processing. The French CNIL adds that most large audience measurement offerings fall outside the exemption whatever their configuration.

Why consent is required before Clarity loads

Article 5(3) of the ePrivacy Directive is the rule that applies here, and its structure is what trips people up: storing an identifier on the device, or reading one back, is allowed only once the visitor has consented, unless it is strictly necessary for the service they asked for. Session recordings and heatmaps are useful to you, not necessary to the visitor, so the consent has to come first, at page load, before the first _clck is written.

3. Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing.

— ePrivacy Directive, Article 5(3)

Two more points complete the picture. Data leaves for Microsoft in the United States: Microsoft states in its privacy statement that it complies with the EU-U.S. Data Privacy Framework, whose adequacy decision the EU General Court upheld in September 2025 (an appeal is pending before the Court of Justice). That covers the transfer question, not the consent question. And recordings can capture personal data typed or displayed on your pages, so masking sensitive fields is your job too.

What Microsoft changed on 31 October 2025

Microsoft’s consent management documentation is unusually direct:

• Since 31 October 2025, Clarity enforces consent signal requirements for visits from the European Economic Area, the United Kingdom and Switzerland. Microsoft adds that this “does not introduce new consent requirements”, it enforces the existing ones.
• Consent Mode is on by default for visitors from those regions. Until Clarity receives a valid signal, the consent state is “denied”.
• Without consent, Clarity runs in a no-consent mode: no cookies, a unique ID per page view, and features that depend on cookies (session recordings across pages, funnels) may be limited.
• Consent is treated as valid for up to 9 months, unless the visitor changes it.
• With ad_storage granted, Clarity shares data with Microsoft Ads; with it denied, it does not.

The no-consent mode is a good-faith design, but notice what it still does: the script runs on the visitor’s device and sends interaction data. The EDPB’s Guidelines 2/2023 on the technical scope of Article 5(3) (final version adopted on 7 October 2024) apply that article well beyond cookies, to tracking pixels and URL tracking among others. “No cookie” is therefore not the same as “no consent needed”. The cautious choice for a small business is simple: no request to Clarity at all before the visitor says yes.

How the WebLegal cookie banner handles Clarity

Our free cookie consent banner (CCB) has Clarity in its built-in catalogue, in the analytics category. Concretely:

1. Detection. Every script or iframe whose URL matches the signature [./]clarity\.ms(?![\w-]) is caught. That covers the tag loaded from www.clarity.ms and Clarity’s collection endpoints on *.clarity.ms, while the boundary at the end avoids false positives such as clarity.msu.edu.
2. Blocking before consent. The request never leaves the browser until the visitor accepts the analytics category. A visitor who refuses gets no Clarity at all, not even the no-consent mode.
3. Consent signal. Before any tag runs, the banner sets Google Consent Mode defaults to “denied”, then sends analytics_storage and ad_storage updates according to the visitor’s choice. Microsoft documents that Clarity reads Google Consent Mode signals automatically. A visitor who accepts analytics but refuses marketing therefore gets Clarity with ad_storage denied: no sharing with Microsoft Ads.
4. Withdrawal. If the visitor later withdraws consent, the banner deletes the first-party _clck and _clsk cookies. Third-party cookies on Microsoft’s domains are out of reach of any banner on your site, which is exactly why blocking before consent matters.

If you want belt and braces, you can also pass the decision through Clarity’s own Consent API v2 by listening to the banner’s event:

<script>
  window.addEventListener('wl-cc-consent', function (e) {
    if (typeof window.clarity !== 'function') return;
    window.clarity('consentv2', {
      analytics_Storage: e.detail.analytics ? 'granted' : 'denied',
      ad_Storage: e.detail.marketing ? 'granted' : 'denied'
    });
  });
</script>

Two installation rules make or break all of this. The banner script goes first in the <head>, without defer or async, and never through a tag manager: it can only block what has not been requested yet. And a tracker written directly in your HTML can be fetched by the browser before any script runs, so the banner page explains how to neutralise such tags with type="text/plain" and data-wl-src.

Check your own site in two minutes

1. Open your site in a fresh browser profile, open DevTools, and look at the Network tab before clicking anything. Any request to clarity.ms at this stage is a request sent without consent.
2. In the Application tab, look for _clck or _clsk. They should not exist before consent.
3. After accepting, run the check Microsoft documents in the console:

clarity('metadata', (d, upgrade, consent) => {
  console.log('consentStatus:', consent);
}, false, true, true);

You should see analytics_storage: "GRANTED" once the visitor has accepted analytics.

Or let a tool do it: our free GDPR compliance checker loads your page like a first-time visitor and lists the trackers that fire before consent, Clarity included.

What to put in your cookie policy

Clarity must appear in your cookie policy with its purpose (session recording and heatmaps), its provider (Microsoft Corporation), the cookies above and the fact that data is processed in the United States under the Data Privacy Framework. If you do not have a cookie policy yet, every WebLegal pack includes one, starting with the Essential pack at €19.90 (privacy policy + cookie policy).

Clarity is one of 37 services we track. The others that usually travel with it, Hotjar, the Meta Pixel and Google Tag Manager, are covered in the 37 trackers your cookie banner must block, and Hotjar has its own guide: Hotjar and GDPR.