1ConsentConsentDocs
Custom consent designs

Your first custom design

Start with the supplied framework-specific design. You need active custom-design access and an authoring role; evaluation access also works.

1. Create in the right scope

Open Designs in your organization, project, or app. Create a design collection, then add a design for GDPR, TCF, or US, or clone an existing custom banner. Dashboard-created designs customize only the notice and start with the supplied framework-specific notice and its components. A clone retains its original banner/full mode.

Organization resources can be reused in child projects/apps; project resources in that project's apps; app resources belong to that app. Inherited resources are read-only at the receiving scope: edit at the owning scope or clone locally. When an individual design uses collection-shared files, cloning creates an independent collection at the target scope containing that design and a copy of its shared components and CSS. It uses one design and one collection capacity slot. Existing local overrides keep their precedence, and later edits to the original collection do not change the clone. Designs without shared files clone independently without creating a collection. Clones keep their framework type and banner/full mode. A GDPR design cannot be assigned to a US or TCF framework.

2. Open the banner editor

Open the new design. Use Banner HTML to edit main.1cl.html and Banner CSS to edit styles.css. Both are saved atomically with Save draft. Conflicting changes from another editor are reported; your unsaved text remains available to copy before reloading.

The developer workspace can contain additional notice partials and variables. It does not contain authored preference-center or trigger views in banner mode.

Developer file reference

FilePurpose
main.1cl.htmlFirst-layer notice
details.1cl.htmlFull designs only; official managed view for a custom banner
trigger.1cl.htmlFull designs only; official managed reopening control for a custom banner
styles.cssBanner CSS, or view CSS in a full design
vars.cssToken overrides and custom CSS variables
Other .1cl.html partialsReusable buttons, toggles, service lists, and other components

Seeded required files can be edited but not renamed or deleted. Collection-level files provide defaults; design-local files with the same name override them. A local styles.css replaces the collection file rather than appending: retain rules you still need.

3. Change only the notice

In main.1cl.html, add brand-notice to the existing notice wrapper. Retain its other classes, attributes, children, commands, labels, and disclosures. This snippet illustrates the wrapper change, not a replacement for the full seeded notice:

<div class="oc-notice brand-notice" role="dialog" aria-modal="false" aria-label="{{ ui.title }}">
  <h2>{{ ui.title }}</h2>
</div>

Append a scoped rule to the existing styles.css:

.brand-notice .oc-notice__title {
  letter-spacing: -0.02em;
  max-inline-size: 28ch;
}

Keep the full existing body, legal links, choice controls, preferences link, and framework-specific content. For a custom banner, the official secondary views have their own compiled components and CSS. Your local notice components cannot replace them. Keep notice selectors scoped so the banner remains easy to maintain.

4. Assign and preview

In the editor, choose a matching CMP. For a shared design, choose its app first. If needed, select Use in this CMP and preview; this explicitly changes that CMP’s draft assignment. You can also select the design in the framework’s layout/design settings. Save your banner to refresh the real CMP preview. Check the changed notice, then open preferences and the reopening button. Saving source or selecting a design does not publish to Live.

Test enabled languages, small viewports, keyboard access, and configured light/dark modes. Try Accept all, Reject all, granular selections, Save, and Cancel where present. Reload to verify the saved decision and reopen to change it.

TCF can be edited and previewed during public beta, but general TCF publication remains restricted. The add-on does not remove that restriction.

5. Review and publish

Use Dashboard publication review. Confirm framework, stage, source changes, and custom-design release, then publish when Preview is correct. Live uses an immutable version; later source saves remain drafts until another publication. Pro can use optional Staging. See publishing.

Your published banner and the reviewed official secondary version are captured together. With a full custom design, all published views are your own frozen copies, and your developer maintains them.

On this page