Debug Microsoft Clarity in Chrome DevTools

What Clarity traffic looks like

Microsoft Clarity streams compressed session recordings, not per-event hits. There is no event= parameter to eyeball; the signal is request pattern and cookies.

Endpoint pattern

Bootstrap script from www.clarity.ms/tag/<projectId> (the project ID in that URL is the one to match against your Clarity workspace), then periodic uploads to collection endpoints on clarity.ms

Transport

Periodic POST uploads of compressed, batched captures: DOM snapshots, mutations, pointer movement, scroll positions; the bodies are not meaningfully human-readable, and a steady beacon cadence is what confirms a recording is in progress

Payload

Custom tags and events pushed via the clarity() API travel inside the same compressed uploads rather than as separate readable requests

Cookies

_clck the persistent user ID · _clsk the session ID linking page views into one recording

Debugging Clarity with Event Watcher

• No dedicated parser. Given the compressed recording format, that is the honest representation: requests are identified by hostname and labeled with the platform name and Session Replay category badge.
• Each request shows its parsed URL parameters, headers-derived cookie data, and body as-is.
• The Cookies section shows _clck and _clsk being set and sent, with direction badges, enough to verify identity and session continuity.
• The practical value is presence, cadence, and consent: is Clarity loaded on the right pages, and when do upload beacons start relative to the CMP.

Clarity and consent

Event Watcher checks Clarity against analytics consent. Session replay deserves a stricter eye than a pageview pixel: a pre-consent recording means user behavior (including text that masking rules fail to catch) was captured before permission existed.

Tag requests and upload beacons that appear before the CMP resolves are marked pre-consent and counted in the violations tally.

In Clarity's consent API mode (script loads but withholds cookies until clarity("consent") is called), watch whether _clck/_clsk appear in the Cookies section before or after the banner interaction.

Common debugging scenarios

• Recordings missing for a page. Check whether the clarity.ms/tag/<projectId> request fires there at all; a tag-manager trigger scoped too narrowly is the usual cause.
• Wrong project receiving sessions. Read the project ID from the tag URL in the stream and compare it against the workspace you expect. Duplicated GTM containers ship stale IDs surprisingly often.
• Recording before consent. Compare the timestamp of the first upload beacon against the CMP interaction; pre-consent beacons are flagged by the consent check.
• Sessions fragmenting across pages. Inspect _clsk in each event's Cookies section. If the session cookie is not being sent on subsequent pages, recordings split.
• Who added Clarity? The Script Tree view attributes the loader to the site's code, GTM, or a third-party script.