Migrating from legacy custom CSS

If you already customized the older consent banner (Display Settings CSS, the published cm.css file, or a data.css link on your airgap.js script tag), use this guide before you rely on Custom CSS in Consent Experiences.

For how to turn Consent Experiences on, see Enabling Consent Experiences. For how to enable Custom CSS and attach a theme stylesheet after you enable, see Custom CSS for Consent Experiences.

Turning on Use New Consent Experience and publishing does not copy your old styles into Consent Experiences. On the next publish:

  • The live consent UI stops using your legacy Display Settings stylesheet (cm.css) and any site-level data-css override meant for the old UI.
  • Your old CSS files and Display Settings are still saved in the Admin Dashboard. You can turn Consent Experiences off later and they still work for the legacy UI. They just do not style the new experience.
  • The new consent UI uses a different layout and HTML structure. Rules written for the old banner will not match the new one as-is.

Work through these steps with your team to successfully use custom CSS for Consent Experiences.

  1. Inventory what you use today. Note whether styling lives in Display Settings, a hosted CSS file, a data-css attribute on the airgap.js tag, or a mix. Capture screenshots of the current banner and preference view for comparison later.
  2. Turn on Consent Experiences in a non-production bundle first when you can, and rebuild core branding in the Theme Editor (colors, logo, fonts, layout). Many teams find they need less custom CSS after this step.
  3. Decide what still needs Custom CSS. Only move rules the Theme Editor cannot express.
  4. Enable Use Custom CSS, pick a Consent Manager UI version, and attach your new stylesheet URL on the relevant theme(s). Do not paste the old stylesheet unchanged and expect it to work. See Custom CSS for Consent Experiences.
  5. Rewrite selectors for the new UI with your team. Target the Consent Experiences structure for the version you pinned, then preview the banner and preference modal on your site.
  6. Publish and verify. Check desktop and mobile, and confirm the old styles are no longer required for the live experience. Leave or remove site-level data-css only after confirming nothing still loads the legacy UI.
  7. Keep a rollback plan. Because switching is reversible, you can turn Consent Experiences off if you need the legacy UI and its CSS temporarily. Coordinate that change with a publish.