[email protected]
0333 050 1245

7 steps to cookie banner design that blocks scripts before consent (UK)

  1. Home
  2. »
  3. Blog
  4. »
  5. Top 5 Best Branding Platforms for Businesses in 2026

A compliant cookie banner gives visitors a genuine choice: accept or reject non-essential cookies, with both options equally visible on the first layer, no pre-ticked boxes, and no cookie wall blocking access. Non-essential scripts must stay dormant until consent arrives, and every banner needs a permanent, easy-to-find way to change your mind later. Get those five things right and the design work becomes far simpler.

TL;DR:

  • Accept and reject options must appear equally on the first layer, styled with the same visual weight, and free from pre-ticked boxes or cookie walls.
  • Scripts for non-essential cookies should only fire after explicit user consent, with proper code gating and detailed consent logging.
  • The first-layer message should be brief and clear, with granular category preferences and accessible design, including high contrast and touch targets.
  • Regular audits and network checks are necessary to ensure scripts are properly gated and the banner remains compliant over time.
  • Custom, tested banners designed with a full understanding of the site and scripts outperform generic solutions and better ensure ongoing legal compliance.

Table of Contents

Most banners fail before a designer even opens Figma, because whoever briefed the project skipped straight past PECR and UK GDPR. Under UK cookie regulation, website owners need valid, freely given, informed consent before setting any cookie that isn’t strictly necessary. That consent has to be a clear positive action. Nobody can imply it, assume it, or bury it three clicks deep.

Not every cookie needs asking permission first. Strictly necessary cookies, the ones that keep a shopping basket populated or a login session alive, are exempt. Everything else, analytics, advertising, personalisation, third-party embeds, needs an opt-in before it fires. That timing detail trips up more sites than any visual design flaw: scripts loading the moment a page renders, rather than the moment a visitor clicks “Accept”, is one of the most common technical failures regulators flag.

The ICO’s own template letter to non-compliant organisations makes the enforcement priority explicit: users must be able to refuse non-essential cookies as easily as they accept them. If “Reject” sits behind a “Manage preferences” link while “Accept All” gets a bright, oversized button on the banner itself, that’s a compliance breach, not just a style choice.

Here’s the checklist that keeps a cookie consent banner on the right side of the law:

  • Timing: no non-essential cookie or script fires before the visitor consents.
  • Parity: accept and reject appear on the first layer, styled with equal visual weight.
  • No pre-ticked boxes: every optional category starts switched off.
  • No cookie walls: visitors can’t be forced to accept cookies just to view content.
  • Granularity: separate categories (analytics, marketing, functional) rather than one blanket toggle.
  • Record-keeping: you log what was consented to, when, and by what mechanism.

The compliance reality check: the EDPB’s cookie-banner taskforce found that asymmetric accept/reject buttons and scripts firing before consent are among the most frequent failings across the banners it reviewed. Both are design decisions, not accidents.

Recent updates to UK cookie compliance under the Data (Use and Access) Act have tightened the list of what counts as exempt and sharpened the ICO’s expectations around prior blocking. The direction of travel is consistent: less tolerance for scripts that “just happen” to load early, and more scrutiny on whether reject really is one click away.

None of this is about lawyers scoring points over designers. A PECR and UK GDPR checklist reads almost identically whether it’s written by a law firm or a design agency, because the requirements are specific enough to leave little room for interpretation. Timing, parity, no pre-ticks, no walls, records kept. Design around those five constraints and the legal risk mostly takes care of itself.

Design principles for a user-friendly, compliant banner

Compliance and good design aren’t in tension here, they’re the same job. A cookie banner that nudges visitors toward “Accept All” through colour, size, or copy is both a UX failure and a legal one, because the ICO treats nudging as evidence that consent wasn’t freely given.

Parity of choice is the principle that does most of the heavy lifting. If “Accept All” is a solid lime button and “Reject All” is grey text with no border, you’ve designed a dark pattern even if you didn’t mean to. Both buttons should carry the same size, the same visual weight, and sit at the same level in the hierarchy. Neutral labelling matters too: “Reject” reads fairly; “No thanks, I don’t want a better experience” is emotional manipulation dressed up as copy.

Information hierarchy decides whether anyone actually reads the thing. The first layer needs one clear sentence explaining what’s being asked and why, not a paragraph of legal boilerplate. Save the granular category breakdown, the named third-party vendors, the retention periods, for a second layer that opens on request. Cramming everything into layer one either overwhelms visitors into clicking “Accept” just to make it go away, or it gets ignored entirely, which defeats the purpose of asking.

Avoid persuasive design entirely. That means no countdown timers implying urgency, no dismissible-only “Accept” button that leaves “Reject” unreachable, and no colour psychology that makes one option feel like the “normal” path and the other feel like opting out of something valuable. The EDPB’s guidance is blunt about this: any design choice that steers a visitor toward one outcome undermines the legal validity of whatever they clicked.

Then there’s the format decision: modal or bar?

  • Disruptive modal (full overlay): forces a decision before the page is usable, best for sites handling sensitive data, higher-risk sectors, or audiences unlikely to scroll down to a footer bar.
  • Lightweight bar (bottom or top of screen): less intrusive, suits content sites and smaller businesses where the browsing experience matters more and cookie use is lower-risk.
  • Slide-in panel (corner): a middle ground, visible but non-blocking, works well on media-heavy or visually led sites where a full modal would clash with the brand.

The ICO explicitly accepts that some disruption is sometimes necessary to secure genuinely informed consent. Chasing the smoothest possible aesthetic at the expense of clarity isn’t a neutral trade-off, it’s a compliance risk. If your audience needs a modal to actually notice the choice they’re making, use one.

Pro Tip: Test your banner with the browser window at 375px wide before you test anything else. Most parity failures (reject button getting squeezed off-screen, accept button ballooning to fill the space) only become visible once you’re designing for a thumb, not a mouse.

Brand tone still has a place here. A confident, characterful banner doesn’t need to sacrifice neutrality: playful copy is fine as long as the actual choice architecture, the buttons, the sizing, the order, stays scrupulously even-handed.

Copy is where good intentions quietly collapse. A banner can have perfect parity in its layout and still fail because the wording implies consent that was never actually given, or hides a category behind vague language nobody would recognise as “advertising cookies.”

Here’s what compliant first-layer wording tends to include:

  1. A plain-language purpose statement: “We use cookies to run this site and, with your permission, to understand how it’s used and show relevant ads.” One sentence, no jargon, states the actual purpose rather than a generic “we value your privacy.”
  2. Two equal-weight primary actions: “Accept All” and “Reject All” (or “Reject Non-Essential”), same size, same style, same row.
  3. A visible third option: “Manage Preferences” or “Cookie Settings,” positioned so it doesn’t compete visually with the two primary buttons but isn’t hidden either.
  4. Named categories in the preferences panel: “Strictly Necessary” (always on, explained why), “Analytics,” “Functional,” “Advertising,” each with its own toggle defaulting to off.
  5. A link to the full policy, clearly labelled “Cookie Policy” or “Privacy Policy,” not buried in footer grey text at 10px.

Now the patterns that quietly fail:

Ambiguous continuation language is the most common one: “By continuing to browse, you accept our use of cookies.” Scrolling isn’t a positive action under PECR, so this phrasing implies consent that was never actually granted. Equally problematic is the single-button banner, “Got it!” with no reject option at all, which the ICO treats as a straightforward breach because it removes the choice entirely rather than presenting it unevenly.

Vague category naming causes a subtler failure. Labelling a toggle “Improve your experience” instead of “Analytics” or “Personalisation” technically offers a choice, but it doesn’t give visitors enough information to make an informed one, which is exactly what UK GDPR requires. And pre-ticked toggles inside the preferences panel, even when the main banner buttons show good parity, invalidate consent the moment someone clicks “Save” without touching them, because they never took a positive action on those categories.

Use the exact labels “Accept All,” “Reject All,” and “Manage Preferences” (or close variants) rather than inventing cleverer alternatives. Regulators and users alike have learned to recognise these terms; novelty here creates confusion, not delight.

Where a banner sits on the page shapes how many people actually engage with it rather than blind-clicking past it. Bottom-of-screen bars feel least intrusive and suit content-heavy sites, but they’re also the easiest to ignore, which can undercut the “informed” half of informed consent. Centred modals demand attention and work well when cookie use is higher-risk, though they interrupt the first impression of the page. Corner slide-ins split the difference reasonably well for e-commerce and portfolio sites.

Accessibility isn’t optional polish here, it’s part of what makes consent valid, because a control nobody can reach or read isn’t really offering a choice. A few non-negotiables:

  • Contrast ratio of at least 4.5:1 between text and background, per WCAG guidance, on both buttons, not just the accept button.
  • Tap targets of at least 44×44 pixels on mobile, with enough spacing that a thumb doesn’t accidentally hit “Accept” while aiming for “Reject.”
  • No overlap with existing UI elements, back buttons, chat widgets, sticky headers, that could obscure the reject option on smaller screens.
  • Keyboard focus that moves automatically into the preferences panel the moment it opens, rather than leaving keyboard users stranded on the trigger button.
  • ARIA labelling on every interactive element, so screen reader users hear “Reject All non-essential cookies, button” rather than an unlabelled generic control.

Where most mobile banners fail: cramming three unequal-sized buttons into a viewport under 400px wide almost always squeezes the reject option out of easy reach, the exact parity failure the ICO’s guidance warns against, just achieved through neglect rather than intent.

Keyboard focus management deserves particular attention because it’s the accessibility failure designers most often overlook. When a “Manage Preferences” panel opens, focus needs to jump straight into it, landing on the first toggle or close button, not left sitting uselessly on the button that triggered it. Screen reader users navigating by tab order otherwise have no way of knowing the panel even opened.

A banner that looks flawless but doesn’t actually stop tracking scripts is worse than no banner at all, because it creates a false impression of consent while data collection continues regardless. Visual hiding, a script tag that’s still present in the page’s source but wrapped in a hidden <div>, does nothing to stop that script executing. Gating has to happen at the code or tag-manager level.

The practical sequence developers should follow:

  1. Classify every script running on the site into essential and non-essential before writing a line of banner code. This audit, tedious as it sounds, is where most gaps get found.
  2. Wrap non-essential tags in a condition tied to consent state, not page load. In Google Tag Manager, this typically means firing analytics and advertising tags only on a custom consent_granted event, rather than on the standard page-view trigger.
  3. Fire the consent event only after a genuine user action, the click on “Accept All” or the specific category toggle, never on page load or as a default state.
  4. Log the consent record: timestamp, which categories were accepted or rejected, and the mechanism (banner button vs preferences panel), stored somewhere retrievable if a regulator or the visitor asks what was recorded.
  5. Verify with a fresh, unauthenticated load, incognito window, cleared cookies, and check the browser’s DevTools network tab. If a Google Analytics or ad-tracking request fires before any click, the gating has failed regardless of what the banner displays.
  6. Re-test after rejection, not just after acceptance. A surprising number of implementations correctly block scripts pre-consent but fail to stop them if a visitor clicks “Reject,” because the code only checks for the positive case.

Pro Tip: Run the network check twice, once immediately after page load and once thirty seconds later. Some scripts are delayed deliberately to dodge quick manual audits, but they still count as firing before consent if a visitor never interacted with the banner.

Consent storage doesn’t need to be complicated. A first-party cookie or local storage entry recording category-level choices, paired with a server-side log for audit purposes, satisfies most needs without exposing more personal data than necessary. Keep the record itself privacy-preserving: you’re storing a consent decision, not building a new tracking mechanism to replace the one you just gated. A properly configured content management setup makes this considerably easier to maintain than bolting consent logic onto a site that was never built with it in mind.

Four patterns cover almost every legitimate use case, and picking the wrong one is usually a mismatch between site type and interruption tolerance rather than a design failure.

  • Bottom bar with two equal buttons: works for content sites, blogs, and portfolios where cookie use is limited to analytics. Compact, low-friction, easy to build with equal parity by default.
  • Centred modal with category breakdown visible: suits e-commerce and any site running advertising pixels or third-party marketing tags, where the volume of non-essential cookies justifies asking for real attention.
  • Footer link plus floating icon for ongoing withdrawal: a small, persistent icon (often a cookie graphic or shield) in the corner, always accessible, lets visitors change their consent choice months after their first visit without hunting through a privacy policy.
  • Slide-in panel from a screen edge: a reasonable middle ground for SaaS products and service sites, visible without blocking the whole page, but still able to carry a full category breakdown if triggered.

Whichever pattern you choose, the copy and button styling should still follow brand guidelines, typography, colour palette, tone of voice, provided the actual choice architecture stays neutral. A banner that looks like it belongs to nobody’s brand is just as jarring to a visitor as one that looks aggressively sales driven.

For inspiration beyond generic templates, look at how sites in regulated sectors (finance, healthcare, legal) handle their first layer. They tend to over-invest in clarity precisely because the compliance stakes are higher, and that discipline usually produces better UX for everyone, not just risk-averse industries. Reviewing a handful of banners across different sectors before starting a build tends to surface pattern ideas faster than staring at a blank Figma file.

Building this properly follows a sequence, and skipping steps is exactly how sites end up retrofitting compliance six months after launch.

  1. Audit every cookie and script currently running on the site, categorising each as strictly necessary or non-essential. Browser extensions and your hosting platform’s own cookie scanner both help here, but manual verification catches what automated tools miss.
  2. Design the first-layer experience with equal-weight accept and reject buttons, one-sentence purpose copy, and a visible link to a preferences panel.
  3. Build the preferences panel with named, toggleable categories, all defaulting to off, plus a save button that only applies once clicked.
  4. Implement script gating at the tag-manager or code level, tying non-essential scripts to a genuine consent event rather than page load.
  5. Set up consent logging, recording what was chosen, when, and through which mechanism, in a format you can retrieve later.
  6. Test on desktop and mobile using a fresh, incognito browser session, checking DevTools network activity to confirm nothing non-essential fires before a click, and re-testing after a reject click specifically.
  7. Publish, then monitor. Track consent rates (how many visitors accept versus reject), watch for complaints or unusual drop-off, and schedule a review every six to twelve months, particularly given how often ICO guidance and exemption lists get updated.

A few practical questions come up at almost every stage of this process. Does every site need a preferences panel, or can a simple accept/reject bar suffice? If your site only runs strictly necessary and basic analytics cookies, a two-button bar with no granular panel can be compliant, provided reject genuinely blocks the analytics script. Should the banner reappear on every page? No, a single first-layer decision should persist site-wide via the stored consent record, reappearing only if that record expires or the visitor clears their cookies. What happens if someone ignores the banner entirely? Non-essential cookies simply stay blocked; only strictly necessary cookies should be active by default, so inaction never becomes implied consent.

A banner that was compliant at launch can drift out of compliance within months, usually because a marketing team adds a new tracking pixel without looping in whoever built the consent logic. Ongoing testing isn’t paranoia, it’s maintenance.

Fresh-load network checks should happen on a recurring schedule, not just at launch. Open an incognito window, clear all cookies, load the homepage, and watch the DevTools network tab for any request to an analytics or advertising domain before you’ve clicked anything. Then click “Reject All” and repeat the check, since a script that respects the initial block but ignores rejection is just as non-compliant.

Automated scanning tools can flag new third-party scripts added since the last audit, catching the marketing-team-adds-a-pixel scenario before it becomes a six-month compliance gap. Pairing automated scans with a manual quarterly review catches what tools miss, particularly scripts loaded conditionally or via third-party embeds that don’t show up in a simple crawl.

User testing for clarity matters as much as technical testing. Sit five people down with the banner and ask them to explain, in their own words, what clicking each button does. If more than one person can’t tell you what “Reject” actually blocks, the copy needs work regardless of whether the code is technically correct.

The record-keeping standard worth adopting: store each consent decision with a timestamp, the specific categories accepted or rejected, and which mechanism captured it, banner button or preferences panel, so you can answer a regulator’s or a visitor’s query without reconstructing history from server logs.

Recent regulatory tightening makes this record-keeping discipline more relevant, not less. Exemptions have narrowed, and demonstrating that you gated scripts correctly at a specific point in time carries real weight if a complaint ever lands.

Kukoocreative’s take: when to DIY and when to bring in help

We’ve spent over a decade partnering with business owners on the parts of a website that determine whether it actually converts, and cookie banners sit at an odd intersection: legally load-bearing, but frequently treated as an afterthought bolted on the day before launch. That’s backwards. Get the banner wrong and you’re either leaking data illegally or annoying every single visitor who lands on your site, sometimes both.

DIY works fine for straightforward cases: a brochure site running Google Analytics and nothing else, built on a platform with a decent consent-management plugin, managed by someone comfortable poking around in Tag Manager. The risk climbs fast once you’re running multiple ad platforms, embedded third-party widgets, or a custom-built site where “just add a plugin” isn’t an option.

That’s usually where we get the call. Cookie banner work rarely arrives on its own, it’s normally part of a wider conversation about building web systems that don’t bottleneck growth, because a site slow enough to need performance work is often the same site that’s never had a proper script audit either.

A professional audit typically covers three things: a full inventory of every script currently firing, a gap analysis against ICO requirements, and a rebuild of the consent layer that’s tested against fresh-load network checks before it ships, not after a complaint arrives.

Most businesses treat their cookie banner as a five-minute plugin install, and most of the time, that’s fine right up until a regulator’s automated scanner or a curious competitor checks the DevTools network tab. We’ve watched a client’s marketing agency add a new ad pixel eighteen months after launch, quietly reintroducing exactly the pre-consent tracking their original banner had been built to prevent. Nobody noticed for months, because nobody was checking.

The real trade-off isn’t UX versus compliance, it’s ongoing attention versus a one-off build. A banner designed once and never revisited will drift out of compliance as your marketing stack evolves, no matter how well it performed on launch day.

If you take one thing from this: schedule a network-tab check every time you add a new tracking script, not just when you first build the banner. That single habit catches more compliance drift than any amount of upfront design polish.

— Kukoo

Kukoocreative is the practical alternative to patching a generic plugin and hoping it holds: rather than a one-size template, you get a banner audited against your actual scripts, designed to match the electric, confident visual identity your brand already carries, and built with proper script gating rather than a hidden <div> pretending to be compliant.

Kukoocreative

Our process starts with the same audit outlined above, every script classified, every gap identified, before a single button gets designed, and it slots naturally alongside broader brand identity work if your banner is overdue a visual refresh anyway. We’ve built this into full website systems for growing UK businesses for over a decade, which means the consent layer we hand over comes tested, logged, and genuinely gated rather than cosmetically compliant.

If your current banner was installed in an afternoon and never looked at again, that’s worth fixing before it becomes a bigger problem. Start with our logo design brief process to scope a wider project, or browse the portfolio to see how we’ve handled brand and web work for businesses like yours, then get in touch to request a cookie banner audit alongside it.

Sources

For readers who want the original guidance rather than a summary of it: