In short
Consent must be freely given, specific, informed and unambiguous, which means declining has to be as easy as accepting and nothing non-essential may load before a choice is made. Most banners fail on at least one of these. The most effective design decision is to reduce what you actually need consent for — a site using privacy-first analytics and no third-party tracking may need no banner at all.
What the rules actually require
Under European data protection rules, consent for non-essential cookies must be freely given, specific, informed and unambiguous. Several practical requirements follow.
Nothing non-essential loads before consent. Analytics and marketing scripts must wait. A banner that appears after the tracking has already fired is decoration.
Declining must be as easy as accepting. An Accept All button next to a Manage Preferences link is not equivalent effort, and regulators have said so repeatedly.
No pre-ticked boxes. Consent must be an active choice.
Withdrawal must be as easy as giving it. People need an ongoing route to change their mind.
Access cannot be conditional on accepting non-essential cookies, except in narrow circumstances.
Most banners in the wild fail at least one of these, usually the second.
Why they are so bad
Because they are usually implemented to satisfy a legal checkbox rather than to obtain a genuine decision, and because a consent management platform is dropped in with default settings nobody reviews.
The result is the familiar pattern: a large accept button, a small link that leads to a page of toggles, and a banner covering the content the person came for.
That design is optimised to produce accepts, which is precisely why it fails the freely given test. The design that annoys people and the design that fails compliance are the same design — which is convenient, because fixing one fixes the other.
The banner that works
Two equivalent buttons. Accept and Decline, same size, same prominence, same visual weight. A third for settings is fine, positioned as the less common path.
Say plainly what it is for. "We use cookies for analytics to understand how the site is used" tells someone what they are deciding. A paragraph of legal language does not.
Do not cover the content. A bar at the bottom is usually better than a centred modal, and it is far better than a full-screen overlay that must be dismissed before anything can be read.
Do not block the page. If someone ignores it, they should still be able to read.
Remember the answer. Asking on every page load is both irritating and a signal the implementation is wrong.
Provide a way back. A link in the footer to reopen preferences satisfies the withdrawal requirement and takes an hour to build.
Respect the signals people already sent
Some visitors have already expressed a preference at the browser level, through Do Not Track or Global Privacy Control.
Honouring those is straightforward, reduces the number of people who see a banner at all, and is a clear signal that the consent mechanism is genuine rather than performative. In some jurisdictions Global Privacy Control is treated as a legally valid opt-out.
The best banner is no banner
The question worth asking before designing one: what do we actually need consent for?
Essential cookies — session, security, load balancing, and the record of the consent choice itself — do not require consent. If those are all you set, you need no banner.
That is achievable more often than people assume. Privacy-first, cookieless analytics measures traffic without personal data. Self-hosting fonts and scripts removes third-party requests. Removing the tag manager nobody audits removes whatever it was loading.
The measurement trade-off is real but smaller than expected — and worth weighing against the fact that consent-gated analytics only measures the people who consented, which biases everything you conclude from it. Complete data about everyone often beats detailed data about a self-selecting subset, as covered in what analytics to track.
Auditing what you actually set
Most teams do not know. Open developer tools on a fresh session and look at what is stored before any interaction, then again after accepting.
You will typically find scripts nobody remembers adding, a tag manager loading things marketing added years ago, and an embed pulling in tracking as a side effect.
That audit is usually the highest-value hour available here, because it frequently turns a complicated consent problem into a simple one — and every third-party script removed is also a performance improvement.
The short version
Audit what you set. Remove what you do not need. Then, if you still need consent, give people two equivalent buttons, plain language, a banner that does not block the page, and a way to change their mind.
That is compliant, it is less annoying, and it takes less work than the elaborate version.
If you are not sure what your site is currently loading before consent, book a call — the answer is often surprising.
Common questions
What makes a cookie banner compliant?
Nothing non-essential may load before a choice is made, declining must be as easy as accepting, no boxes may be pre-ticked, withdrawal must be as easy as giving consent, and access cannot be conditional on accepting. Most banners fail on the second of these.
Is an 'Accept All' button with a settings link compliant?
Generally not. Consent must be freely given, and a prominent accept button beside a small link to a page of toggles is not equivalent effort — regulators have said so repeatedly. Provide a decline button of equal size and prominence alongside accept.
Do I need a cookie banner at all?
Only if you set non-essential cookies. Session, security, load-balancing and the consent record itself are essential and need no consent. A site using privacy-first cookieless analytics, self-hosted fonts and no third-party tracking often needs no banner.
Should a cookie banner block the page?
No. A bar at the bottom is better than a centred modal, and far better than a full-screen overlay that must be dismissed before anything can be read. If someone ignores it, they should still be able to use the site — blocking access is itself a compliance risk.
How do I find out what cookies my site actually sets?
Open developer tools in a fresh session and inspect storage before any interaction, then again after accepting. Teams usually find scripts nobody remembers adding, a tag manager loading things from years ago, and embeds pulling in tracking as a side effect.
