The cookie banner is the first thing a new visitor sees on most European-facing sites, and it is usually the worst-designed element on the page: a full-width bar with two buttons of unequal weight, blocking the content, appearing after a delay so it also shifts the layout.
Almost all of that is fixable, and some of it is a legal requirement rather than a design preference.
When you need one at all
The uncomfortable first question, because a large share of banners exist for cookies the site does not need.
Strictly necessary cookies - a session, a cart, a CSRF token - do not require consent. Analytics, advertising and most embeds do. So the cheapest way to make the banner smaller is to need less: server-side analytics without cross-site identifiers, self-hosted fonts, and a facade for third-party embeds so nothing loads until the reader clicks.
A site that genuinely only sets a session cookie does not need a banner, and shipping one anyway trains readers to dismiss consent without reading it.
The components
Cookie Banner by Arunachalam is the standard shape, Cookie Consent by Bankk is the version with category controls, and Cookies Banner by shadway and CookieConsentBanner by rahul jangir are the alternatives.
The rules that are actually rules
Not design opinions. These come from how consent law is enforced, and getting them wrong is the common reason a banner is non-compliant despite existing.
Reject has to be as easy as accept. One click, at the same level, in the same visual weight. A prominent "Accept all" next to a faint "Manage preferences" that leads to a second screen is the pattern regulators have specifically ruled against.
Nothing non-essential fires before consent. A banner that appears while the analytics script has already loaded is decoration. The scripts must be gated on the stored decision.
No pre-ticked boxes. Consent is opt-in; categories default to off.
Withdrawing must be as easy as giving. A persistent link in the footer that reopens the preferences, which is what that footer slot is for.
Store the decision, with a date and a version. Consent expires, and if your categories change you need to ask again rather than assume the old answer covers the new tracker.
Making it not ruin the page
Do not block the content. A bar at the bottom, or a small card in a corner, is enough. A full-screen overlay before anyone has read a word is also, for a mobile visitor arriving from search, exactly the kind of interstitial that guidance on intrusive interstitials describes.
Render it with the page, not after. A banner injected on mount pushes the layout down, which lands in Cumulative Layout Shift. Reserve its space or render it server-side.
It is a dialog if it traps, and not one if it does not. A non-blocking bar is a region with a heading. If you do block, it needs the full dialog contract from the dialog guide: focus in, focus trapped, and a real heading.
Keyboard first. The two buttons must be reachable and clearly focusable, and the banner should not be the last thing in the tab order if it is the first thing on screen.
One occupant of the top or bottom strip. The header guide covers the stack problem: cookie bar plus announcement plus upgrade prompt is three strips before the content.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| A consent management platform | Category gating, regional rules, audit logs and vendor lists | A script, a subscription and a look you partly control |
| Needing fewer cookies | No banner at all, which is the best banner | Server-side analytics and embed facades take work |
| shadcn/ui | Card, Button and Switch as the parts | The gating logic is yours |
| 21st | Banners and consent cards with category controls | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a consent banner, get the previews inline, and let the agent write the file.
Frequently asked
- Does every site need a cookie banner?
- No. Strictly necessary cookies such as a session, a cart or a CSRF token do not require consent. Analytics, advertising and most third-party embeds do. Needing fewer cookies, through server-side analytics, self-hosted fonts and embed facades, removes the banner entirely, which is the best outcome available.
- Does reject have to be as easy as accept?
- Yes. One click, at the same level and the same visual weight. A prominent accept-all beside a faint manage-preferences that leads to a second screen is the pattern regulators have specifically ruled against, and it is still the most common implementation.
- When should analytics scripts load?
- After consent, never before. A banner that appears while the analytics script has already run is decoration, not consent. The scripts have to be gated on the stored decision, and the decision needs a date and a version so that changing your categories triggers a fresh ask.
- Where should a cookie banner sit?
- A bar at the bottom or a small card in a corner, rendered with the page rather than injected on mount so it does not shift the layout. A full-screen overlay before anyone has read a word is also, for a mobile visitor from search, exactly the kind of intrusive interstitial guidance warns about.