CSS color-mix() in 2026 — The Complete Guide to Dynamic Palettes, Opacity Blending and Theme Tokens

color-mix(in <color-space>, <color-1> <percent?>, <color-2> <percent?>)

/* Equal blend — 50/50 by default */
color-mix(in oklch, #a855f7, white);

/* 80% of the first, 20% of the second */
color-mix(in oklch, #a855f7 80%, white);

/* Same idea, but using a CSS variable */
color-mix(in oklch, var(--brand) 80%, white);

/* Mix toward transparent — replaces rgba() */
color-mix(in srgb, var(--brand) 12%, transparent);

Why this matters for design tokens: if you generate hover, active, and disabled states by mixing your base color with white or black, the choice of color space decides whether those states look like the same color "got brighter" or whether they look like they shifted hue. OKLCH keeps the hue locked. sRGB does not.

Pattern 1: A full palette from a single brand token

This is the killer use case. Define one brand color. Derive everything else with color-mix(). No more hand-tuning eleven shades for every product surface.

:root {
  --brand: oklch(0.59 0.22 295);

  --brand-50:  color-mix(in oklch, var(--brand) 8%,  white);
  --brand-100: color-mix(in oklch, var(--brand) 16%, white);
  --brand-200: color-mix(in oklch, var(--brand) 32%, white);
  --brand-300: color-mix(in oklch, var(--brand) 50%, white);
  --brand-400: color-mix(in oklch, var(--brand) 75%, white);
  --brand-500: var(--brand);
  --brand-600: color-mix(in oklch, var(--brand) 85%, black);
  --brand-700: color-mix(in oklch, var(--brand) 70%, black);
  --brand-800: color-mix(in oklch, var(--brand) 55%, black);
  --brand-900: color-mix(in oklch, var(--brand) 40%, black);
}

Change the one --brand declaration at the top — from purple to teal to crimson — and every shade updates with it. No regenerated Sass, no rebuilt design tokens, no JS. The browser does it.

For deeper, dedicated ramps you'd hand-tune in production, the same trick still beats hardcoding by a wide margin. Combine it with a live palette generator when you want to start from a curated base instead of a raw OKLCH coordinate.

Pattern 2: Replace rgba() for overlays and tints

The old pattern for a 12% brand-colored hover background was rgba(168, 85, 247, 0.12). That works, but it has two problems: you have to remember (or compute) the RGB triplet, and it doesn't react if your brand color changes. color-mix() with transparent solves both:

.btn-ghost:hover {
  /* Old way */
  background: rgba(168, 85, 247, 0.12);

  /* 2026 way — token-driven, no triplet */
  background: color-mix(in srgb, var(--brand) 12%, transparent);
}

Why in srgb here? Because you're mixing toward transparent, which has no color, only alpha. The hue interpolation behavior of OKLCH is wasted — and sRGB is slightly faster for the renderer to compute. Save OKLCH for cases where both endpoints are real colors.

The same pattern unlocks tinted surfaces over photography, status-color badges that pick up the page's accent automatically, and the "subtle tint on row hover" effect that every data table needs.

Pattern 3: Dark mode without a second palette

The traditional dark mode pattern is to write two complete palettes — one for light, one inside :root.dark. It works, but you're maintaining everything twice. With color-mix(), you can flip one variable and let the surfaces re-derive.

:root {
  --surface: white;
  --text: oklch(0.15 0.02 295);
  --brand: oklch(0.59 0.22 295);

  --bg-elev:    color-mix(in oklch, var(--surface) 92%, var(--brand));
  --bg-subtle:  color-mix(in oklch, var(--surface) 96%, var(--brand));
  --text-dim:   color-mix(in oklch, var(--text) 60%, var(--surface));
}

:root.dark {
  --surface: oklch(0.13 0.01 295);
  --text:    oklch(0.95 0.01 295);
  /* --brand and everything derived stay the same declarations */
}

The elevation and subtle tints automatically blend with whatever --surface is, so dark mode "just works" with two variable overrides instead of forty. This is the same pattern Material 3 and the GitHub Primer system use under the hood — you just don't need a token build pipeline to do it anymore.

For more on building a dark theme that actually feels right (not just inverted), the dark mode color palette guide walks through the harder design questions.

Pattern 4: Hover, focus and disabled from any base

This is the pattern that makes component libraries clean. Every interactive element gets its states from color-mix() instead of magic numbers:

.btn {
  background: var(--btn-bg);
  color: var(--btn-fg);
}
.btn:hover {
  background: color-mix(in oklch, var(--btn-bg) 88%, white);
}
.btn:active {
  background: color-mix(in oklch, var(--btn-bg) 85%, black);
}
.btn:disabled {
  background: color-mix(in oklch, var(--btn-bg) 40%, var(--surface));
  color:      color-mix(in oklch, var(--btn-fg) 50%, var(--surface));
}

A primary button with --btn-bg: var(--brand-500) and a danger button with --btn-bg: var(--red-500) share the same hover formula, the same active formula, the same disabled formula. The interaction language stays consistent without any per-variant overrides.

Pattern 5: Accessible text on dynamic backgrounds

A useful trick for cards and chips where the background is user-driven: derive the text color by mixing the background toward whichever pole has more contrast.

.chip {
  --chip-bg: oklch(0.85 0.10 50);
  background: var(--chip-bg);
  /* Push text toward the opposite end of the lightness axis */
  color: color-mix(in oklch, var(--chip-bg), black 85%);
}

This isn't a replacement for proper WCAG contrast checking — for that, follow the accessible contrast ratios guide — but it's a strong default that prevents the worst failures when your design system has to accept arbitrary brand colors from customers.

Browser support and fallbacks

As of May 2026, color-mix() is supported in:

• Chrome / Edge 111+ (March 2023)
• Firefox 113+ (May 2023)
• Safari 16.2+ (December 2022)

Global usage is at roughly 96.5% — the same band as CSS Grid was when it became "just use it." The remaining 3.5% is overwhelmingly legacy mobile WebViews and stale embedded browsers. For those, the standard pattern is a static fallback before the dynamic value:

.surface {
  background: #f3e8ff; /* static fallback */
  background: color-mix(in oklch, var(--brand) 10%, white);
}

Browsers that don't understand the second line keep the first. No @supports needed for the common case.

Common pitfalls

Forgetting the in <space>

The color space argument is required. color-mix(red, blue) is invalid and the rule will be dropped. Always lead with in oklch, or in srgb,.

Percentages that don't sum to 100%

If your two percentages sum to less than 100%, the result is multiplied by that fraction toward transparent. So color-mix(in oklch, red 30%, blue 30%) gives you a 60%-opaque mix, not what you probably wanted. Make them sum to 100% or leave one off entirely.

Using HSL when you want OKLCH-style results

HSL takes the shorter path around the hue wheel, which is sometimes what you want and often what surprises you. If you're aiming for "perceptually even between these two endpoints," reach for OKLCH and don't look back.

Mixing variables that aren't valid colors

If var(--brand) falls back to something that isn't a color (an empty string, a typo), the whole color-mix() call is invalid and discarded silently. Always set a fallback: var(--brand, oklch(0.59 0.22 295)).

When NOT to use color-mix()

color-mix() is a runtime function. That's its superpower for theming, but it's also its limit. A few cases where you should still pre-compute:

• Brand assets — logos, favicons, and exports for print need fixed values, not browser-computed ones.
• Email — clients don't support color-mix(). Use hex.
• Static SVG you export — if the SVG ships outside the browser context, inline the actual color value.
• Performance-critical animations on huge surfaces — the difference is small, but a static color avoids re-resolving the mix per frame.

For everything else — design tokens, component states, theming, overlays, dynamic surfaces — color-mix() is the right default in 2026.

The takeaway

The era of needing a build step to compute color variations is over. With one CSS function and a handful of patterns, you can ship a full design system that derives its palette, its states, its overlays, and its dark mode from a single brand token. Less code, fewer files, less drift between Figma and production.

Start with one brand color you trust, define it as a CSS variable, and let color-mix() do the rest. If you need to pick that starting color first — or want a brand-safe set of bases to choose from — the Color Palette Generator is the fastest way to get there.