Hotjar Heatmap and Session Recording Cookie Consent Integration Guide: 2026 Playbook for Publishers
Hotjar holds a unique place in the tooling stack. It is not a web analytics platform like Google Analytics, not a product analytics platform like Amplitude or Mixpanel, and not a tag manager. It is a user-experience research tool that exists specifically to record what individual users do on a page — where they move their mouse, what they click, where they scroll, where they hesitate, and, in the case of session recording, exactly what they typed and saw rendered on screen. That granularity is the product. It is also why regulators have singled out session replay as one of the highest-risk categories of behavioural processing, and why a careless Hotjar deployment is one of the easiest ways for an otherwise compliant website to fall out of compliance. The CNIL, the Garante, and the EDPB have all published guidance specifically targeting session-replay behaviour, and the 2026 EDPB cookie banner task force is treating it as a priority category. The good news is that Hotjar is one of the better-engineered tools in the category for consent-first deployment — provided the publisher actually uses the controls that exist.
Why Hotjar requires explicit consent
Hotjar's collection profile is what triggers consent obligations across every framework that matters. On a default initialisation the Hotjar tracking script writes at least three first-party cookies — _hjSessionUser_{siteId}, _hjSession_{siteId}, and a series of suppression and incoming-source cookies — into the browser within milliseconds of page load. The script then begins streaming a continuous record of cursor coordinates, click coordinates, scroll position, viewport size, and, when session recording is enabled, the full rendered DOM diffed against a baseline.
Under Article 5(3) of the ePrivacy Directive every one of those cookies is a storage-and-access operation that requires prior, freely given, specific, informed, and unambiguous consent in the EEA, the UK, Switzerland, and any jurisdiction that has imported the same standard. Under the GDPR the behavioural stream constitutes processing of personal data because the combination of cursor trace, IP address, device fingerprint, and session identifier is sufficient to single out an individual. Under the CCPA and CPRA the same collection counts as a sale or share unless the publisher has the relevant service-provider contract with Hotjar — which Hotjar offers via its CCPA-compliant DPA, but only takes effect when the integration is configured correctly. Under the EDPB's session-replay guidance the bar is higher still: replay must be tied to a specific, legitimate UX-research purpose, the retention period must be the minimum necessary, and the data subject must be informed not only that recordings exist but that their own session may be replayed by an analyst.
What Hotjar collects before consent — and what must be suppressed
The most common implementation mistake is the one that ships with Hotjar's own quickstart: pasting the tracking script directly into the page <head>. That works, but it loads Hotjar before the cookie banner has even rendered, which means cookies are set and behavioural recording begins on the very first page view — regardless of what the user later decides. Every EU regulator that has ruled on this pattern has ruled the same way: cookies set before consent are unlawful, and the publisher is liable.
A compliant integration must therefore prevent the Hotjar script from loading at all until the relevant consent category has been granted. The cleanest way to do this is to wrap the Hotjar snippet inside a consent-gated <script> tag that the CMP injects only after the user has opted into the analytics or product-research category. If the script is loaded via a tag manager the equivalent is to set the trigger to a consent-granted event rather than to All Pages. Hotjar's own documentation now recommends this pattern explicitly, and the platform exposes a hj('consent', 'grant') API for cases where the script must be present but should remain dormant until consent is recorded.
Cookies and storage Hotjar writes
The Hotjar Tracking Code 6.x writes the following identifiers, all of which are non-essential and require consent: _hjSessionUser_{siteId} with a 365-day expiry containing the user identifier, _hjSession_{siteId} with a 30-minute expiry containing the session identifier, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress, and a number of campaign-attribution cookies when surveys or feedback widgets are active. Session recordings themselves are stored on Hotjar's servers and keyed to the session identifier — withdrawing consent must therefore also signal a deletion request through Hotjar's API or the in-product user-deletion flow.
Mapping Hotjar to consent frameworks
Hotjar does not natively integrate with IAB TCF or the IAB Global Privacy Platform. It is not an ad-tech vendor and was never intended to be one. It does, however, integrate with Google Consent Mode v2 via the analytics_storage signal, and it exposes its own native consent API that any CMP can bind to. The pattern that survives a regulator's review treats each Hotjar capability as a separate consent gate.
- Heatmaps and click maps bind to the analytics or product-research purpose. In TCF terms this is most commonly purpose 8 (measure content performance) combined with purpose 1 (store and/or access information). For Consent Mode this is analytics_storage.
- Session recording should sit behind a stricter, separate signal. Recording captures the rendered DOM and any unmasked field, and an explicit preferences-level opt-in — not blanket analytics consent — is the defensible posture under the EDPB's session-replay guidance.
- Surveys and feedback widgets can run under the same consent gate as session recording when they collect free-text input, or under the analytics gate when they only collect rating data.
- Funnels and conversion tracking bind to the analytics gate; if any user identifier is propagated to a CRM or ad platform the marketing gate also applies.
The integration pattern that works
The reference deployment has four parts: a CMP that exposes a real-time consent change event, a deferred script loader that only injects the Hotjar snippet after analytics consent fires, a session-recording suppression layer that defaults recording to off until a separate gate opens, and an input-masking configuration that hard-suppresses any field a regulator would consider sensitive even when consent has been granted. The fourth point is often overlooked: input masking is not a substitute for consent, but it is a substitute for catastrophe when consent is granted for legitimate research and a user happens to paste sensitive data into a free-text field.
Web implementation
On the web the cleanest pattern is to subscribe to the CMP's consent change event, then conditionally inject the Hotjar snippet when the analytics purpose flips from false to true. Use document.createElement('script') to inject the tracking code with the async attribute set, and attach an onload handler that calls hj('identify', userId, properties) only if a server-validated user identifier exists. When consent is withdrawn, call hj('consent', 'revoke'), expire all _hj cookies via document.cookie, and dispatch a deletion request via the Hotjar Data API for the user's prior session recordings. Do not lazily initialise Hotjar in the same render pass as the banner — the script must wait for an explicit grant, and the grant must be recorded with a timestamp and consent string before the script ever fires.
Input masking and sensitive-data suppression
Hotjar's session recorder ships with three masking modes: Suppress mode, which is the default for password fields and any element marked with the data-hj-suppress attribute; Whitelist mode, where only explicitly opted-in inputs are recorded; and Mask mode, where keystrokes are recorded as asterisks. Under the GDPR's special-category rules and the CCPA's sensitive-personal-information definition, any field that could capture health information, financial detail, government identifiers, biometric data, precise geolocation, or contents of private communications must use Suppress mode regardless of the user's consent state. Setting data-hj-suppress at the form level rather than the field level is the safest pattern — it suppresses the entire form even if a developer later adds a new field that they forget to mark individually.
Single-page applications and route changes
For SPAs (React, Vue, Angular, Svelte) the Hotjar snippet binds to the initial page load only by default. To track virtual page transitions the bootstrap must call hj('stateChange', newPath) on every route change. This call respects whatever consent state Hotjar holds at the time, so the CMP gating logic does not need to be duplicated — but the route change must not itself trigger a fresh script load if consent has been withdrawn between page views.
Validating the integration
The validation step is what regulators check and what publishers most often skip. A correctly integrated Hotjar deployment must pass four tests in order. First, a fresh browser session with the banner shown but no choice made should produce zero requests to static.hotjar.com, script.hotjar.com, or vars.hotjar.com, and zero _hj cookies in document.cookie. Second, declining analytics should keep that state — no script load, no recording, no cookies. Third, accepting analytics should produce a script load and the expected _hjSessionUser and _hjSession cookies with correct SameSite attributes, and a heatmap recording should appear in the Hotjar dashboard within five minutes. Fourth, withdrawing consent after the fact should immediately stop further recording, expire the cookies, and trigger a deletion request — a delayed cleanup is a finding.
The audit trail matters separately. Regulators expect the publisher to be able to prove, for any given recording in the Hotjar account, that the user who generated it had given valid consent at the moment of capture. The standard pattern is to embed the consent version and timestamp as a custom attribute on the Hotjar user record via hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). That makes any specific recording traceable back to a specific consent log entry, which is the standard the EDPB has set and the standard publishers should adopt regardless of where they operate. A correctly gated deployment, paired with input masking that suppresses by default and a deletion path that activates on withdrawal, is what makes Hotjar a defensible part of a research stack rather than a compliance liability.