What it is
Hotjar reconstructs sessions, aggregates interactions into heatmaps, and runs feedback widgets. Like other replay tools it records interaction detail rather than counting events, so what it captures depends heavily on how it is configured.
Because the cookie names all begin with `_hj`, the classifier matches the prefix rather than enumerating them. New Hotjar cookies are therefore attributed correctly without a catalogue change.
What a scan matches
A verification scan drives a real browser and records the outbound requests observed during its configured journeys, so Hotjar is identified by request hosts and paths rather than by source-code claims. Requests on unvisited paths, after unperformed interactions or solely on the server remain outside that observation.
- hotjar.com
- hotjar.io
Cookies are classified by name before domain because many analytics and advertising tags write first-party cookies through the page, which places a vendor-related identifier on your domain. Matching known names helps attribute those values without assuming that every first-party cookie came from your own application.
| Cookie | What it is for |
|---|---|
| _hjSessionUser_* | Persistent user identifier per site |
| _hjSession_* | Current session state |
| _hjIncludedInSessionSample | Whether this session is being recorded |
| _hj* (others) | Hotjar writes a family of cookies; the classifier matches the whole prefix |
Controlling it with consent
No named adapter. Declare it as a custom script attached to analytics, or gate it as a container tag.
Hotjar suppresses keystroke data in input fields by default, but its suppression and masking settings still deserve a review, particularly for sensitive text rendered outside form inputs, URL data, account pages and any custom configuration.
No named adapter: choose the appropriate control
The product ships named adapters for Google Tag Manager, Google Analytics, the Meta and TikTok pixels, and Klaviyo. Choose the control route that fits this technology: a custom HTTPS script declaration for a browser loader, an individual consent condition inside a tag manager, a platform or app setting, or a click-to-load placeholder for a frame. Server-side integrations need their own enforcement because a browser runtime cannot stop them.
What breaks if it is refused: recordings, heatmaps and feedback widgets for refusing visitors.
Verifying it
Before consent there should be no request to hotjar.com or hotjar.io and no _hj cookies. Watch for the survey widget specifically: it is sometimes installed separately from the recording script.
- Before a choice: optional tracking endpoints and optional identifiers are absent; any intentionally loaded necessary or functional surface matches the control model described above
- After rejecting optional categories: optional activity remains absent and the refusal persists across a reload
- After granting the relevant category: the expected loader or embed appears and the feature behaves normally
- After withdrawing: new optional activity stops; where the vendor supports a consent signal, verify that the signal is sent as well as checking network behavior
Common questions
Does Hotjar need consent?
Treat it as consent-required in prior-consent jurisdictions. It sets persistent identifiers and records behaviour, neither of which is strictly necessary to deliver a page the visitor asked for.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Hotjar: suppressing keystrokes in collected data
Vendor documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.