Consent Docs
Open console

Banner and tag problems

Fix a banner that does not appear, tags that run too early or never run, and a site policy that blocks the consent script.

Troubleshooting5 min readFor anyone with something not working

Find the problem by what you see on your page. Open the browser's network panel first and look for the request to /sdk/v1/form.

The form request answers 401#

What you see: No banner. In the network panel, GET /sdk/v1/form answers 401.

Why it happens: The key did not accept the page. The answer is the same for each cause:

  • The page's origin is not in the key's Allowed origins.
  • The page was opened from disk. A file:// page has no origin.
  • The key is live and the page runs on localhost. A live key answers only the origins on its list.
  • The key is revoked.

Fix: For local work, serve the page from http://localhost and use a test key. For any other address, create a key that lists the origin. A key's origins cannot be edited later. See Create a key.

The response says the form is null#

What you see: No banner. The response to /sdk/v1/form has "form": null.

Why it happens: No region rule covers the place you are in. Nothing is asked there and no tag is held.

Fix: To try a place that a rule covers, add data-piedap-country="IN" to the tag. Remove it before you go live, or every visitor gets the form for that one place. To show a form in the countries no rule reaches, add an Everywhere else rule. See Choose regions.

A privacy button shows but no banner#

What you see: No banner, only a round privacy button.

Why it happens: This browser already answered. The banner comes back on its own only when the answer expires, a new version asks something new, or a region rule now picks another form.

Fix: Run this in the browser console to be asked again:

JavaScript
await PiedapConsent.reset();

A private window also starts clean. See Test your integration.

No form request is sent#

What you see: No request to /sdk/v1/form. The browser console shows a message that starts [piedap-consent].

Why it happens: The runtime did not start. The message names the cause:

  • Add data-piedap-key to the script tag: the tag has no key. A tag loaded as a module, or through a bundler import of its address, cannot read its own attributes.
  • data-piedap-key must be a publishable key: the key does not start with pk_.

Fix: Use a plain script tag with data-piedap-key="pk_…". If the tag held an sk_ key, revoke that key and create a new one. For bundled code, use the npm package. See Install on a website.

Tags run before the visitor answers#

What you see: Before any choice, the network panel shows requests to a tracker.

Why it happens: A tag that ran before the runtime cannot be recalled. The usual causes:

  • The consent tag is not the first script in <head>, or it has async or defer.
  • A script optimiser moved or bundled the tag.
  • The runtime was loaded by Google Tag Manager or the npm package, so scripts earlier in the page had already run.
  • The tracker's host is not on the list of known hosts.
  • The tracker is an image pixel, a fetch call or a stylesheet. Only scripts and iframes are held.

Fix: Put the tag first in <head> without async or defer. Mark any tag the runtime does not know with type="text/plain" and data-consent. See Hold tags until consent.

What you see: Requests to googletagmanager.com or google-analytics.com before the visitor answers.

Why it happens: Google's tag hosts are left off the blocking list on purpose. Google tags load and follow Google Consent Mode, which starts with the signals denied.

Fix: Check that the first Consent Mode entry is the default:

JavaScript
window.dataLayer
  .filter((entry) => entry[0] === 'consent')
  .map((entry) => Array.from(entry));

To hold Google Tag Manager until a category is allowed, add its host to blockedHosts. See Google Consent Mode.

A tag stays blocked after Accept all#

What you see: The visitor allows everything, but a chat widget, a video or a marked script never loads.

Why it happens: A tag is released when its purpose or category is allowed.

  • The form has no purpose in the tag's category. A category the form does not ask about is never allowed.
  • data-consent names a purpose key in the wrong case. Purpose keys are case sensitive.
  • data-partner names a partner the purpose does not list.
  • The tag was added to the page after the choice. It waits for the next change of choice.

Fix: Add a purpose in that category to the form, or exempt a strictly necessary host with allowedHosts. For tags you add from JavaScript, wait with PiedapConsent.whenGranted(). See Hold tags until consent.

A site security policy blocks the script#

What you see: The browser console reports a Content Security Policy error. The banner is missing or unstyled, or an allowed tag does not run.

Why it happens: Your policy does not allow what the runtime does. With Trusted Types enforced, a choice that releases a held script fails and is not recorded.

Fix: Allow the deployment's origin in script-src and connect-src, and 'unsafe-inline' in style-src. Load held tags from files with src, because a released inline script counts as inline. With Trusted Types, define a default policy. See Set up a Content Security Policy.

A pinned script stops running#

What you see: After you change the version in a pinned tag, the browser refuses the script and no banner shows.

Why it happens: The integrity hash belongs to one exact build. A tag with a new version and an old hash does not run.

Fix: Change the version and the hash together. Take both from Install, under Website, Other ways to install, Pinned + SRI. See SDK versions.

Still stuck#

Collect these before you ask for help:

  • the address of the page and the key's hint, such as pk_…Nimw
  • the status and the response of /sdk/v1/form, and its X-Request-Id header
  • any browser console message that starts [piedap-consent]
  • the runtime version, from PiedapConsent.version

Add data-piedap-debug to the tag to see the full region trace in the response.

↑↓ to move, Enter to open