Does HubSpot need cookie consent?

All posts

Yes, in the EU and UK, if the HubSpot script runs on your site. HubSpot lists __hstc and hubspotutk as non essential analytics cookies and its ad pixels as advertising. Hold the script until consent or pass HubSpot the choice. Gating your Meta and LinkedIn tags is not enough, because HubSpot can load those pixels itself.

Which HubSpot cookies need consent?

The rule in the EU is Article 5(3) of the ePrivacy Directive, and the UK has its own version in PECR: storing something on a visitor’s device needs consent unless it is strictly necessary for the service they asked for. In the US most state laws work differently, as an opt out, which the US state privacy laws post covers.

HubSpot’s own cookie list does most of the sorting for you:

• Analytics, needs consent: __hstc, hubspotutk, __hssc and __hssrc. The first two last six months.
• Advertisement, needs consent: Facebook, LinkedIn and Google pixels installed through HubSpot’s ads tool.
• Necessary, no consent: the cookies that remember the choice itself, such as __hs_cookie_cat_pref and __hs_do_not_track, plus security and membership login cookies.

Live chat is the one to read closely. HubSpot treats messagesUtk as necessary when its chat cookie consent setting is on. When that setting is off, a separate consent setting on the chatflow governs it, so check both before you sort it.

Why do HubSpot’s ad pixels load when your tags are blocked?

Because they do not come from your tags. On a live estate we audited in August 2026, the Meta and LinkedIn tags in Tag Manager were correctly gated and did not fire. The network trace still showed the HubSpot script loading js.hsadspixel.net/pixels.js, which injected both pixels with the same IDs.

We read the scripts HubSpot served in November 2026 to see why. The HubSpot loader adds pixels.js next to its analytics file, on both of the loaders we checked. You can open that file and search for addPrivacyConsentListener. It does not look at your container. It listens to one thing, HubSpot’s own consent state, and only asks HubSpot for the pixel list when the advertisement category reads true. We ran the file against a stub to confirm it: no answer and a false answer sent no request, and a true answer fetched the list.

Now the part that catches sites using another consent tool. In the same banner script, when no HubSpot cookie policy matches the page, consent is set to allowed for every category. A site that switched its banner to another tool and left no HubSpot policy behind is therefore telling the pixel file yes, whatever the visitor clicked elsewhere. HubSpot does not describe this default in the pages we read and scripts change, so treat the trace below as the proof for your own site.

Is HubSpot’s own cookie banner enough?

It can be, for HubSpot’s own cookies. HubSpot’s example is the Facebook pixel: installed through its ads tool, with opt in required, it cannot set cookies until the visitor opts in. It also says the banner covers only HubSpot’s cookies, and that pixels added by hand in your site header are outside its control. If the rest of your site runs other tags, you still need something governing those, and two banners asking one visitor the same question is the setup to avoid.

How do you hold HubSpot until a visitor consents?

There are four routes. Pick by what else runs on the site and what you want to keep for visitors who decline.

• HubSpot’s banner is your only banner. In Settings, under Privacy & Consent, give every page and region you care about a cookie policy that requires opt in.
• Hold the whole script with your consent tool. In Tag Manager, add a consent check to the HubSpot tag and fire it on your platform’s consent update event as well as page load. If it carries pixels, gate it on advertising, or an analytics only choice releases them. The cost: the loader also brings HubSpot’s analytics, collected forms and pop ups, so visitors who decline get none of them.
• Keep the script and tell HubSpot the choice. HubSpot’s cookie banner API documents this: set window.disableHubSpotCookieBanner = true near the top of the head, then push setHubSpotConsent with analytics, advertisement and functionality values. The value is held in memory, so your code has to send it again on every page, and HubSpot warns that the flag also disables its consent management, so your tool now carries all of it. In the script we read, the flag stops the allowed default above, and the pixel file waits. The API page does not say what the tracking code does before any choice, so check the cookies yourself.
• Take the pixels out of HubSpot. Remove them on the Pixels tab and run them as your own gated tags, then gate HubSpot’s analytics separately. Remove first: HubSpot warns that a pixel installed both ways fires twice. Its pixel file also sends form submission events, so rebuild any you rely on.

Whichever you choose, check it the same way.

1. Trace the page before you change anything

   Open the site on a fresh browser profile with the network panel already open, and click nothing on the banner. Filter for hs-scripts, hsadspixel, connect.facebook.net and snap.licdn.com, then look for __hstc, hubspotutk and _fbp in the cookie list.

2. Find what loaded each request

   Expand the initiator chain on any pixel request. If pixels.js sits directly above it, HubSpot loaded that pixel and no tag in your container did. Why the Facebook pixel still loads when your tags are blocked covers reading the chain.

3. List the pixels HubSpot holds

   In HubSpot, open Settings, then Marketing, then Ads, and read the Pixels tab. Note each network listed, because each one can load from the HubSpot script.

4. Apply one consent route

   Choose one of the four routes above and apply it to every page that carries the HubSpot script. Running two routes on one page makes the result hard to read.

5. Test decline, accept and the return visit

   Repeat the trace three ways: decline and check that the cookies and pixel requests stay away, accept and check that they arrive, then reload as the same visitor and check that the choice holds. How to test a cookie banner before going live has the full sequence.

Your tag manager’s preview will not show any of this, since it describes tags and these requests are not tags. Which consent category a script belongs in helps if HubSpot sits alongside other tools you have not sorted yet.

What do you lose when a visitor declines?

HubSpot says its tracking code can still load and execute after non essential cookies are rejected, recording aggregated, anonymised page views that are not tied to a visitor or a contact. So the second and third routes differ here. Holding the script loses those page views for people who decline; passing the choice keeps them, with the script still running on the page. Neither brings the declined visitor back into your contact records, so expect smaller HubSpot source reports after a correct fix.

Velo holds any script you mark with a consent category until that category is granted, and pushes velo_consent_update for Tag Manager triggers. It does not send HubSpot a consent signal itself, so the third route needs a small script of your own. The HubSpot page covers the install.