Customize with theme variables

Tailwind v4 uses CSS-first theme variables:

@import "tailwindcss";

@theme {
  --color-brand: #2457d6;
  --font-display: "Geist", sans-serif;
  --breakpoint-3xl: 120rem;
}

The variable namespace tells Tailwind which API to extend:

• --color-brand creates color utilities such as bg-brand, text-brand, and border-brand
• --font-display creates font-display
• --breakpoint-3xl creates the 3xl: responsive variant

Theme variables are also emitted as ordinary CSS custom properties, so custom CSS or JavaScript-driven styles can reference the same value:

.chart-line {
  stroke: var(--color-brand);
}

Use @theme when a value should participate in Tailwind’s utility API. Use :root for a custom property that should exist at runtime but should not generate utility families.

Choose tokens from repeated design decisions. A one-off marketing illustration color does not automatically deserve a global name. A brand color used for links, buttons, and focus might—but test whether one value can satisfy every contrast context.

Names can be raw (--color-brand-600) or semantic (--color-action). Raw scales expose palette choices; semantic names communicate purpose and can make theming easier. Many projects use a small semantic layer over a restrained palette.

Custom breakpoints affect every component that uses them. Define them in compatible units and sorted order, then document the content problem they solve. A new device nickname is not enough justification.

Changing a token has a large blast radius. Use visual regression checks and inspect light, dark, hover, focus, and disabled states before treating a theme edit as a harmless color replacement.

Your action is to inventory repeated colors, fonts, and breakpoints in a small page. Promote only three justified values into @theme, replace the repeated classes, and list every state that must be reviewed when each token changes.