A Content Security Policy (CSP) on your own site, an ad blocker, a DNS blocklist, or a browser feature that answers cookie banners hides the TermsFeed Free Cookie Consent banner. You fix your Content Security Policy on your site, and a copy of the Cookie Consent files on your own server avoids a DNS blocklist. The ad blocker and the browser feature are choices the visitor made on their own device, and they hide the consent banner on many sites, not only yours.

The console and the Network tab tell the causes apart. Open the page in the normal window that does not show the consent banner, because a private window does not run extensions by default. Open DevTools and delete the 3 cookies whose names start with cookie_consent_ in the Application tab, so a saved answer does not hide the consent banner. Select the Network tab, type termsfeed in the filter, and reload.

Cause 1: Your Content Security Policy blocks the script

A Content Security Policy that does not allow https://www.termsfeed.com blocks the Cookie Consent loader and script for every visitor. In every browser, the consent banner never appears and no tagged script runs.

The Console tab shows a line that names the address of cookie-consent.js or cookie-consent-code.js with violates the following Content Security Policy directive and the directive at fault, such as script-src 'self'. That line names the policy as the cause.

Allow the TermsFeed host in your policy by adding https://www.termsfeed.com to script-src. Under a nonce-based policy, write your nonce on the loader script tag, the inline run() script, and every tagged script. Copy the directives from The minimum Content Security Policy for Cookie Consent.

Ad blockers and their filter lists for cookie notices block the Cookie Consent requests or hide the consent banner element, for the visitors who use them. uBlock Origin offers lists such as "EasyList – Cookie Notices" and "uBlock filters – Cookie Notices", and Brave applies the EasyList Cookie list by default. Read the Brave announcement of the default in Blocking annoying and privacy-harming cookie consent banners.

A blocked request shows net::ERR_BLOCKED_BY_CLIENT in the Console tab or the Network tab. A hidden consent banner loads normally: the Elements tab holds div#termsfeed-com---nb, but a filter style sets it to display: none, and the Application tab does not list a cookie_consent_user_accepted cookie.

Turn the extension off for your site, or turn Brave Shields off for it, or test in a window without extensions, and confirm that the consent banner comes back. The blocker runs in the browser, so only the visitor turns it off for your site.

Cause 3: A DNS blocklist stops www.termsfeed.com from resolving

A DNS blocklist on the network the visitor uses stops www.termsfeed.com from resolving, so the Cookie Consent files never arrive. Home routers, Pi-hole, company networks, and DNS filtering services apply such lists to every device on the network.

The Network tab shows net::ERR_NAME_NOT_RESOLVED or a connection error for the loader cookie-consent.js, even with every extension off, and no request for cookie-consent-code.js follows. Load the page on another network, such as mobile data, to rule the blocklist in or out. The network owner decides the list. A copy of the Cookie Consent files on your own domain does not make a request to www.termsfeed.com, so the blocklist no longer stops it. That copy does not get the updates and bug fixes TermsFeed ships. Weigh that before you host the files with Self-Host Free Cookie Consent on Your Server.

Some browsers and privacy apps answer consent banners for the visitor, so the Cookie Consent banner disappears with an answer already stored. Cookie Pop-Up Protection in the DuckDuckGo browser apps, for example, hides the Cookie Consent banner and refuses for the visitor. DuckDuckGo clicks the "I decline" button, or, on a consent banner without one, opens the Preferences Center, turns every switch off, and clicks the "Save my preferences" button. Read these steps in the TermsFeed rule of DuckDuckGo Autoconsent.

The stored cookies match those of a manual click on the "I decline" button, so they alone do not tell the 2 apart. Delete the 3 cookies whose names start with cookie_consent_ and reload. The Cookie Consent files load, but the consent banner never shows. The Application tab lists cookie_consent_user_accepted=true again, with every optional category false in cookie_consent_level, although you clicked nothing.

Turn Cookie Pop-Up Protection off in the DuckDuckGo settings, delete the 3 cookies again, and reload: the consent banner comes back. Cookie Consent treats the answer as a normal refusal: tagged scripts outside strictly-necessary stay blocked for that visitor. The visitor changes that answer through the "Update cookies preferences" link at any time.

A blocked Cookie Consent script does not release tagged scripts, so tagged tracking stays off, and strictly necessary tagged scripts never run either, because only Cookie Consent releases them. Leave any script your site needs to work, such as a cart or a login, untagged, so it runs while the Cookie Consent files are blocked. Tag only the scripts you want Cookie Consent to hold, each with its category from The 4 Cookie Categories. Expect no analytics data from visitors who block the Cookie Consent files.

Keep the "Update cookies preferences" link on every page. Where a filter style hides only the consent banner element, the visitor has not answered yet and answers through that link.

Your site is clear when the consent banner shows in a browser without extensions, on a network without a DNS blocklist, with no CSP error. Repeat these steps after every change to your policy. Publish your change and clear any page cache first.

  1. Close every private window, open a new one with extensions off, and open DevTools with F12.
  2. Open the Network tab, type termsfeed in the filter, and load your page.
  3. Confirm that cookie-consent.js and cookie-consent-code.js both return status 200.
  4. Open the Console tab and confirm that no line contains violates the following Content Security Policy directive.
  5. Confirm that the consent banner shows with its styles and its buttons, such as "I agree" ("OK" in implied mode) and "Change my preferences".