Work through the sections in sequence: each produces something the next one needs — a finished configuration, a screenshot baseline, a selector log, a source file, compiled output.

Scope of This Customization

The use of Tailwind is limited to producing CSS for the banner CookieScript already renders; nothing here is a substitute for CookieScript.

• CookieScript renders the interface and injects its markup at runtime.
• CookieScript controls Accept, Reject, and preference behavior.
• CookieScript handles consent according to your configuration.
• Tailwind runs in your own build. You write styles, compile them, and hand CookieScript ordinary compiled browser CSS.
• CookieScript gets compiled CSS only — never Tailwind source syntax.

To reopen the banner or react to a consent change, call CookieScript's documented classes, methods, and events rather than writing your own. Don't rebuild Accept, Reject, or preference logic.

One limit to keep in view all the way through: styling changes appearance. It does not turn on script blocking, consent records, Google Consent Mode, geo-targeting, or legal compliance. Those work only if you've already set them up in CookieScript.

Freeze the CookieScript Configuration

Finish the CookieScript setup before you write any CSS. Your selectors and styles must match the banner a visitor actually gets; thus, you must have a completed banner.

Confirm each of these is in place:

• Paid plan. Custom CSS is only available on paid CookieScript plans.
• Banner installed and loading on the site.
• Design decided: active banner design, layout, position, copy, and the button set (Accept, Reject, and Preferences where they apply).
• Categories and preference controls set, plus the Cookie Declaration if you'll style it.
• Cookie scan complete if you're styling category controls or a populated Cookie Declaration — those controls only render after a scan. Review the detected cookies and their category assignments rather than trusting the scan blindly.
• Market setup decided: which audiences need prior consent, an opt-out interface, or a separate regional banner.
• Integrations recorded: whether IAB TCF, geo-targeting, script blocking, consent recording, Google Consent Mode, and additional languages are on. Each of these changes the labels, controls, and consent states the banner renders — the exact markup you're about to write selectors against.
• Build tools ready: a working Tailwind v4 production build, browser DevTools, and a staging environment.

Handle all the easy changes through CookieScript's built-in design settings first — base colors, position, layout — and reserve Custom CSS for everything else. What's built-in depends on your plan and configuration, so check the current feature list on CookieScript before assuming anything.

The last step here is capturing baseline screenshots of the first-layer banner and open preferences view on both desktop and mobile. Later, when something moves that you did not expect, you will compare it against this.

Check Whether Regional Variants Change the Banner

Practical risk: regional variants change the controls and markup you style. A stylesheet written for one region may miss all the elements rendered by another region's banner because the banner's markup differs by region. Get the regional and legal setup approved before styling — it's wasted effort if you have to rework a variant after it has changed shape.

These two variants illustrate how different the interface can be:

• France / EU-style prior-consent variant. It can appear before non-essential trackers run and include Accept, Reject, and category choices. eprivacy rules generally require prior consent for non-exempt storage or access, and the GDPR defines valid consent where personal data is involved.
• California-style opt-out variant. A covered business may need opt-outs for the sale or sharing of Personal Information, including cross-context behavioral advertising, plus controls for certain sensitive-data uses. This is a different interface model with different controls.

California is one example for the US, not the entire country. The UK, Canada, Brazil, China, Singapore, Japan, and Australia each need separate review — APAC is not one shared banner model — and interpretation varies even within Europe.

Once the variants are approved, route them with CookieScript geo-targeting:

• create a separate banner for each place where behavior differs;
• assign the countries, regions, or US states to each;
• add a Global fallback for visitors who don't match a rule;
• regenerate and redeploy the geo-targeting code after any change;
• test every route.

Two installation rules affect whether GEO-targeting works at all:

• Install geo-targeted CookieScript code directly in the site <head>, not through Google Tag Manager. Global, non-geo-targeted CookieScript code may still use GTM.
• Do not put a fixed integrity/SRI hash on geo-targeted code. The script response can vary by location, so one hash won't match every version.

Two things that do not affect GEO-targeting, so you don't need to worry about them here:

• Self-hosting your compiled Tailwind CSS has no effect on GEO-targeting.
• Self-hosting CookieScript's banner JavaScript, however, disables GEO-targeting — the location check happens on CookieScript's servers, so pulling the script local removes it.

Build a Selector Log From the Rendered Banner

The selectors you style must come from the markup CookieScript actually rendered — not from an example, not from another project, not from memory. This section produces a written log you'll use while writing CSS.

Set up the inspection:

1. Open the site in a private window, or clear your consent state, so the banner loads fresh from the first layer.
2. Inspect the first-layer banner in DevTools.
3. Open the detailed preferences screen and inspect that too. Don't stop at the first layer — the preferences dialog is separate markup with its own structure, so a selector that matches the container on the first layer often matches nothing in the preferences panel.
4. In DevTools, check the Styles and Computed panels for inline declarations and for CookieScript rules with higher specificity. Either can override your CSS even when your selector is correct, so note them now.

Record a row per element. Note the selector, which layer it's on, and which states it exposes (hover, focus, selected, disabled, open) so you don't style only the resting state:

Leave the selector cells to fill in from your own inspection — this guide doesn't ship real CookieScript selectors, because they depend on your banner and version.

Then repeat the whole inspection for every regional banner that adds, removes, or renames controls. Selectors that work on one region's banner can miss on another when the buttons or category controls are different elements. Keep a separate log per variant.

Add CookieScript Styles to the Tailwind Source

Everything so far was inspection. Now write CSS — but it stays in your build for now. CookieScript gets compiled output later.

A Tailwind v4 entry point normally starts with:

@import "tailwindcss";  

If your site already uses Tailwind, reuse that pipeline. Don't import Tailwind a second time just for the banner — add a CookieScript component file to the pipeline you already have. A second full import pulls in Preflight, Tailwind's global reset. On an existing Tailwind site Preflight is probably already applied, so a fresh full import for "just the banner" can reset margins, headings, and form elements across the whole site.

For a dedicated banner-only stylesheet, omit Preflight unless you deliberately want that reset. Import only the layers you need (the no-Preflight snippet is in the compile section below).

Keep the banner styles in their own file so they're easy to scope:

src/styles/  ├── app.css  └── components/      └── cookiescript.css  

Import that file from your main stylesheet, and use the selectors from your log. Here the selector is a placeholder:

/* Placeholder only — swap in a selector you recorded from the rendered CookieScript banner. */  [data-your-banner] {    @apply rounded-2xl bg-white shadow-xl;  }  

[data-your-banner] is a stand-in, not a real CookieScript selector — replace it with what you logged. A few build facts to keep in mind while you write:

• @apply is build-time syntax. Tailwind expands those utilities during compilation, which is why CookieScript must only ever see the compiled output.
• Tailwind v4 detects sources automatically. When you need a utility that isn't being generated, @source inline() can force it.
• Don't inject Tailwind classes with runtime JavaScript. It's more fragile, harder to test across regional banners, and not the approach here.

Write the Banner CSS

Target only the elements in your selector log and the states a visitor can actually reach. Write it in this order: theme tokens, container, text and categories, buttons and focus, then theme-aware behavior.

1. Define theme tokens

Define your brand values once instead of repeating them in every rule:

@theme static {    --color-consent-surface: #ffffff;    --color-consent-text: #111827;    --color-consent-border: #e5e7eb;    --color-consent-action: #2563eb;    --color-consent-secondary: #f3f4f6;    --color-consent-focus: #f59e0b;    --font-consent: ui-sans-serif, system-ui, sans-serif;    --spacing-consent: 1rem;    --radius-consent: 1rem;    --shadow-consent: 0 24px 80px rgb(15 23 42 / 0.22);  }  

That's the minimum set: surface, text, border, action colors, focus, font, spacing, radius, shadow. Use static so the variables are forced into the compiled output. If a variable the banner relies on isn't in the CSS you paste into CookieScript, the banner renders without it — so every variable the banner uses has to survive compilation into the deployed file.

2. Style the container

The container carries most of the layout: surface, border, radius, shadow, padding, max width, and spacing from the viewport edge.

[data-your-banner] {    @apply fixed left-1/2 z-50 w-full max-w-lg -translate-x-1/2 border bg-consent-surface p-4 shadow-consent;    bottom: max(1rem, env(safe-area-inset-bottom));    width: min(32rem, calc(100vw - 2rem));    color: var(--color-consent-text);    border-color: var(--color-consent-border);    border-radius: var(--radius-consent);    font-family: var(--font-consent);    max-block-size: min(90dvh, calc(100dvh - env(safe-area-inset-top) - env(safe-area-inset-bottom) - 2rem));    overflow: auto;  }  

Avoid a fixed height. A banner that fits in English can overflow after translation into a longer language, at 200% zoom, on a narrow phone, under a sticky nav, or when safe-area insets reduce the space. This rule caps height against the viewport with max-block-size, respects the safe-area insets, and lets content scroll inside with overflow: auto.

3. Style text, links, and categories

Set readable sizes, line height, and contrast for the heading and body copy, then handle the specifics:

• Give policy links a non-color cue such as an underline, so they're distinguishable without relying on color.
• Give category names and descriptions their own readable styling.
• Make required or strictly necessary categories read clearly as required.
• On prior-consent variants, don't let optional categories appear pre-selected.
• Style toggles and checkboxes for their selected, unselected, disabled, hover, and focus states — not only the default.

Category styles only apply once the category markup exists: Show Cookie Categories enabled, scan complete, assignments reviewed, and the rendered elements inspected (from the selector-log step).

4. Style buttons and focus

Style Accept, Reject, and Preferences for default, hover, focus, active, and disabled wherever those states exist:

[data-your-accept],  [data-your-reject],  [data-your-prefs] {    @apply min-h-11 rounded-lg px-4 py-2 font-medium;  }    [data-your-accept] {    @apply bg-consent-action text-white;  }    [data-your-reject] {    @apply border bg-consent-secondary;    border-color: var(--color-consent-border);  }    [data-your-accept]:focus-visible,  [data-your-reject]:focus-visible,  [data-your-prefs]:focus-visible {    outline: 3px solid var(--color-consent-focus);    outline-offset: 3px;  }  

The data-your-* names are placeholders — use the selectors from your log. Some UX rules to hold to while styling these:

• Use clear labels, and give Accept, Reject, and Preferences comparable discoverability where that's required.
• Don't hide rejection in faint text, disguise an action as ordinary copy, or pre-check optional categories on prior-consent variants.
• On mobile, let controls stack or wrap instead of cramming them onto one line.
• Accept and Reject don't always have to look identical — that varies by jurisdiction — but neither path should visually disappear.

5. Handle keyboard, focus, and theme behavior

Operate the whole banner by keyboard: focus visible, no keyboard trap, and a way out. Contain focus only when the banner is a genuine modal — and then the page behind it must be inert, with a keyboard-operable way to close or complete it. Check screen-reader reading order and that names, roles, and state changes are announced.

Targets to meet: 4.5:1 contrast for normal text, 3:1 for large text, and pointer targets reaching 24 × 24 CSS pixels unless an exception applies. Confirm 200% text resizing, reflow at 320 CSS pixels, high-contrast mode, reduced decorative motion, and RTL layouts.

Watch dark mode specifically. Your site's dark mode can work while the banner still renders in light mode, because your theme selector — a class on <html>, a data attribute, whatever you use — doesn't reach the markup CookieScript injects. Test the banner inside the active theme context and confirm your dark-mode strategy reaches the injected element.

Compile and Deploy the Output

Tailwind source stays in your source file. CookieScript receives the compiled result.

Pin and test the build with these versions:

npm install tailwindcss@4.3.3 @tailwindcss/cli@4.3.3  npx @tailwindcss/cli -i ./src/cookiescript.css -o ./dist/cookiescript.css --minify  

• Tailwind: tailwindcss@4.3.3. CLI: @tailwindcss/cli@4.3.3.
• Input: ./src/cookiescript.css. Output: ./dist/cookiescript.css.
• Test the final code against that exact Tailwind version. Don't assume 4.3.3 is current unless you've re-checked it on publication day.

Dedicated banner-only build (no Preflight). Start from the layer imports instead of the full @import "tailwindcss":

@layer theme, base, components, utilities;    @import "tailwindcss/theme.css" layer(theme);  @import "tailwindcss/utilities.css" layer(utilities) source(none);    /* Your recorded CookieScript selectors and Tailwind source rules follow. */  

This gives you theme variables and utilities without the global reset, so the banner build doesn't restyle the rest of the page. The dedicated output should include the variables, supporting declarations, and any keyframes the banner needs, and should omit Preflight and unrelated site utilities.

Deploy. Paste the browser-ready compiled CSS into CookieScript at Settings → Colors → Custom CSS Styles. CookieScript loads those rules after its default banner styles.

Alternative: the full site stylesheet. If you're already all-in on Tailwind, you can keep the CookieScript rules in your full compiled site stylesheet instead of a separate file. Don't assume your site CSS automatically wins the cascade.

Check source order, specificity, CookieScript-injected styles, inline declarations, and cache behavior. When an override loses despite a correct selector, the usual causes are a more specific CookieScript rule, an inline style, an unexpected load order, or a stale cached file. Read the live cascade in DevTools rather than reaching for !important.

Never paste Tailwind source directives into CookieScript. Don't hand-copy stray fragments from a large Tailwind build either — use a self-contained dedicated output or the complete tested site stylesheet. These directives belong in your source, not in the Custom CSS field:

@import "tailwindcss";  @theme { ... }  @apply ...;  @source ...;  @variant ...;  

CookieScript expects compiled browser CSS; source syntax just sits inert. That's why @apply "not working" usually means uncompiled CSS reached the field. After deploying, clear the consent state, hard-refresh, and retest both the first layer and the preferences layer.

Add a Persistent Cookie Settings Link

Visitors need a way back to their choices after the banner closes — a footer or privacy-page control. Use CookieScript's documented class and let it handle the click:

<button type="button" class="csconsentlink">    Cookie settings  </button>  

With csconsentlink, CookieScript opens the banner for you, so you write no initialization code. To open it programmatically, CookieScript.instance.show() exists — but instance methods only work once CookieScript has initialized. For code that might run early, wait for the documented event:

window.addEventListener("CookieScriptLoaded", () => {    CookieScript.instance.show();  });  

Avoid javascript: URLs — use the button. Don't build your own Accept or Reject controls; reopening the banner is fine, reimplementing consent isn't.

Test the Banner

Start every test from a cleared consent state, not from a browser that already stored a choice. Clear the consent cookie or consent state, hard-refresh, and run through the banner as a first-time visitor. Test both the first layer and the preferences view throughout.

Visual and accessibility matrix

Run each check on both the first-layer banner and the preferences view:

Functional checks

In a clean session, walk the real decisions: first visit, Accept all, Reject all, a partial category selection, Save preferences, reopen settings, change consent, withdraw consent, move between pages, and return in a fresh browser session. A style that behaves on the first layer can still break the preferences panel, so watch both.

Regional and integration matrix

Consent Mode behaves differently by mode:

• Basic Consent Mode blocks Google tags before interaction and fires them only when the visitor grants consent.
• Advanced Consent Mode can load Google tags with denied defaults and send cookieless measurements.

Don't block the same third-party scripts through both CookieScript and GTM — double-blocking makes problems harder to diagnose.

Troubleshooting Notes

When something breaks, change one thing at a time. A cascade problem and a configuration problem can produce nearly identical symptoms, so isolating one variable is the only reliable way to tell them apart.

Build and compile issues

• @apply appears literally or does nothing → uncompiled Tailwind source reached CookieScript. Compile it and paste only the output.
• Colors or shadows missing → required variables, theme output, or supporting declarations didn't make it into the file. Rebuild a self-contained banner stylesheet.
• Tailwind restyled unrelated elements → Preflight got into a banner-only build. Strip it from the dedicated output.

Cascade and selector issues

• Your CSS won't override CookieScript → wrong selector, source order, specificity, cache, or a changed banner version. Return to your selector log and read the live cascade.
• Mobile banner too tall → spacing, a fixed height, or long translated copy is overflowing. Drop fixed heights and test narrow widths.
• Dark mode doesn't apply → your theme selector isn't reaching the injected banner. Test inside the active theme context.

Regional issues

• The wrong regional banner loads → geo-targeting code wasn't regenerated, or the fallback needs a look. Regenerate, redeploy, and test the Global fallback.

When Custom CSS is Bot Worth It

Custom CSS is optional, not required for every CookieScript setup. Built-in settings handle a lot on their own: color theme, custom and accent colors, opacity, position, layout, button visibility, cookie categories, Cookie Declaration display, and banner text.

Prefer built-in settings when:

• the site doesn't use Tailwind;
• nontechnical people maintain the banner;
• several regional banners would make selector-based overrides hard to maintain.

Reach for Tailwind-generated CSS when the banner needs exact design tokens, real responsive behavior, dark-mode handling, or alignment with a design system.

Why Not Build the Banner From Scratch

Building your own banner means building and maintaining everything behind it: consent state, preference controls, cookie scanning, configured blocking, Google Consent Mode integration, consent records, and regional routing.

CookieScript can cover those, but only when the features you need are available on your plan, enabled, configured, and tested. Styling affects appearance only; the consent handling lives in CookieScript's configuration. Styling does not guarantee legal compliance.

Before Publishing

Run this checklist before you ship:

• CookieScript configuration is final.
• Selectors came from the rendered banner, not examples or memory.
• Tailwind source was compiled.
• The CookieScript Custom CSS field contains only compiled CSS.
• The first layer and preferences panel were tested.
• Regional variants and integrations were tested.
• Confirmed: self-hosted Tailwind CSS does not affect geo-targeting.
• Confirmed: self-hosting CookieScript's banner JavaScript disables geo-targeting.

Managing the Rest of the Consent Setup

Custom CSS only deals with the banner's visual layer. The rest of the consent setup still needs to be handled in CookieScript itself: Cookie Consent, tracking pixels, third-party scripts, blocking rules, records, and integrations.

CookieScript is a Google-certified Consent Management Platform with Gold tier status, which matters if your team uses Google advertising or measurement products.

CookieScript CMP features

The available features depend on the plan and configuration you choose. Some features include:

• customizable cookie banner;
• automatic third-party script and cookie blocking;
• cookie scanning;
• visitor consent recording;
• Google Consent Mode v2 integration;
• Google Tag Manager integration;
• Global Privacy Control support;
• IAB TCF 2.3 integration;
• cross-domain and subdomain consent sharing;
• integrations for Wix, Shopify, Webflow, and other website platforms;
• CookieScript API;
• cookie banner sharing;
• Cookie Policy generator;
• Privacy Policy Generator.

CookieScript offers a 14-day free trial of its Plus plan without requiring a credit card.

Final Thoughts

CookieScript is great if you want to go through a Cookie Banner quickly but with an emphasis on correctness and flexibility. If the default Cookie Banner looks out of place on an otherwise refined website, it is well worth the effort to customize the CookieScript banner.

Regarding spacing, buttons, focus states, and behavior in dark mode, if any of these feel off compared to the rest of the UI, you can "drop in" the Tailwind-generated CSS without fear of breaking any of the consent logic.

That said, it would not justify any of this just because custom CSS is allowed. It is sufficient when the banner looks reasonably good with CookieScript's built-in options. Every new regional variant, selector, or override added increases the testing burden with every change to the banner's configuration.

The best solution is usually somewhere in the middle: let CookieScript handle consent, scanning, blocking, records, and regional behavior; then, use Tailwind when the visuals require more than minor adjustments.

Frequently Asked Questions

Can I use Tailwind CSS for a Cookie Banner?

Yes. Keep Tailwind in your build, compile the file, and paste the generated CSS into the Cookie Banner's custom CSS field. In CookieScript, use plain CSS only — no @apply, @theme, @source, @variant, or @import "tailwindcss".

Why is my cookie banner CSS not working?

Inspect the live cookie banner first. Your selector may not match the rendered element. If the rule appears in DevTools but is crossed out, check specificity, source order, inline styles, cache, or a different banner variant.

Why does the preferences panel look different from the first cookie banner screen?

The preferences panel can use different markup from the first cookie banner screen. It may have its own wrapper, rows, toggles, buttons, and Save control. Inspect it separately and use separate selectors.

Can I paste @apply into cookie banner custom CSS?

No. @apply belongs in the Tailwind source file. The cookie banner custom CSS field will not compile it. If @apply appears on the page, you pasted the source file instead of the compiled CSS.

How do I stop the cookie banner from breaking on mobile?

Remove fixed heights first. Then check button wrapping, long translations, padding, and the preferences panel. Use a viewport-based max height, allow internal scrolling, and let buttons stack when space is tight.

Why is dark mode not changing the cookie banner?

Your dark-mode CSS may not reach the injected cookie banner. Turn dark mode on, inspect the rendered banner, and check whether your theme selector applies. If not, target the actual cookie banner selector.

Do I need different cookie banner styles for different countries?

Only when the cookie banner changes by region. Geo-targeting or regional variants can add, remove, or rename controls. If the markup changes, inspect each cookie banner version separately.

Can custom CSS make a cookie banner compliant?

No. Custom CSS changes the cookie banner's appearance only. Compliance depends on your legal texts, consent choices, blocking behavior, records of consent, applicable regional laws, geo-targeting, Google Consent Mode, and testing.

Should I customize the cookie banner or use the built-in settings?

Use the built-in cookie banner settings whenever possible, as they will be sufficient for most use cases. Using custom CSS makes sense when your cookie banner requires certain design tokens, responsive behavior, dark mode, focus states, or spacing that you cannot implement with built-in controls.

Should I build my own cookie banner instead?

Usually, no. That would leave you with consent states, preferences, scanning, blocking, records, Google Consent Mode, geo-targeting, and regional routing. For most websites, CookieScript should handle the consent logic, and CSS can style the cookie banner.