Customizing the consent banner

Open the customizer

Open your site and go to Banners → Consent banner → Edit. The customizer takes over the full screen, with your settings on one side in a tabbed rail (Content, Design, Categories, Blocking, and Behavior) and a live preview on the other. The preview draws both screens, the banner in the layout you picked and the preference center, with your copy and colors, and it draws every choice as the same button the live banner does. Before you trust any change, switch the preview between the two screens, between desktop and mobile, and between light and dark.

Everything you do here is a draft, and the live banner doesn't change until you publish.

Which layouts are there?

There are five: a box in the bottom-left or bottom-right corner, a bar across the bottom or top, and a centered modal.

On the banner’s first screen, only the centered modal claims aria-modal, because it's the only layout with a focus trap to back that up. Keyboard focus stays inside the dialog until the visitor acts. The other four layouts sit alongside the page, so announcing them as modal to a screen reader would be false.

Set the theme

You control the accent, background, and text colors, plus the corner radius. Dark mode has three settings: follow the visitor's system preference, always light, or always dark. The dark palette is derived from your colors, so you don't have to maintain a second theme.

The accent picker shows a live contrast readout as you drag. The accent fills every consent choice, and the label on it is white or near-black, whichever has more contrast against your accent. Each choice also has a 1px edge. That edge is the accent itself when it stands out from the banner background by 3:1, and otherwise it's the closest shade toward your text color that does. The readout checks the label once, because it sits on the accent in every mode, and the edge once for each palette your dark-mode setting can show, which means both palettes when the banner follows the visitor's system and one when it's fixed. It warns you when the label drops below 4.5:1, the level text needs to stay readable, or when an edge drops below 3:1. You can publish anyway, but an unreadable Reject button is a consent problem as well as a design one.

Which parts of the banner are fixed?

Accept and Reject render as the same button in every layout, with the same accent fill, label color, edge, size, and weight. The preference center's Allow all, Reject all, and Save choices match them, and Reject all is always there, so turning every optional category off takes one click on either screen. When the banner opens, neither choice has focus. None of this is a setting, because an accent-colored Accept beside a plain Reject is the pattern regulators single out, and we don't offer it as an option.

The one way around this is Custom CSS, at the bottom of the Design tab. UserGuard adds it to your page as written. It isn't scoped to the banner, so start selectors from #ug-banner, and it needs !important, because the banner styles its elements inline. A rule aimed at one button won't change the others. Every choice has the class ug-choice and a data-ug-action attribute (accept, reject, or save), so if you restyle one, select them together with #ug-banner .ug-choice. The Preferences button has data-ug-action="preferences" but isn't a choice.

Edit the copy

You can rewrite:

• The preference center copy, including its Allow all and Reject all buttons. Leave Allow all empty to hide it. Reject all always shows, and if you leave it empty it uses your Reject wording.
• Category names and descriptions. Say what "Analytics" means on your site.
• The cookie policy link.
• The re-open control: its corner and its label.

The re-open control is on by default. It's how visitors change their mind after they consent, and withdrawal has to be as easy as consenting was. You choose where it sits and what it says. The Show the re-open control switch can hide it, but that leaves visitors no way back unless your site gives them its own.

Withdrawing does more than stop the next page load. When a visitor turns a category off, UserGuard deletes the cookies in that category that it can reach, matched by name against your approved inventory, so nothing unrelated is touched. There are two kinds it can't reach. Cookies marked HTTP-only are invisible to any script, and a cookie set on a third party's own domain belongs to that domain, where only the browser or that vendor can remove it. The cookies it can reach are cleared on the spot, and again on the next page view in case anything slipped through.

Set the behavior

These settings on the Behavior tab don't affect appearance:

• When the visitor cannot be placed sets what happens when a visitor can't be placed in a jurisdiction. The banner adapts by country, and inside the US every visitor gets the consent model you set, so choose the one your strictest state needs. Ask first (opt-in) fails closed, which means no cookies without consent. Notice and opt-out allows cookies until the visitor objects. Notice only renders a dismissible notice bar and records the dismissal, so even the lightest mode leaves evidence.
• Ask again after is a slider for how many days a consent stays valid before the banner asks again, up to 730. At 0 it reads Never ask again.
• Advanced consent mode lets Google's tags load before a choice, with the consent signals denied. See Google Consent Mode, basic and advanced.

What publishing does

Publishing is versioned and immutable. Each publish creates a numbered banner version that can never be edited afterward, and the only thing that can replace it is the next version. Every consent record names the exact version that was on screen when the visitor acted.

So if a consent is ever questioned, you can answer "what did the visitor actually see" from the record, without having to reconstruct it from memory. You can draft as much as you like, because the preview costs nothing, and the version history starts when you publish.