color-mix(): Dynamic Color Mixing in Tailwind at Runtime

1. The problem with generating a fixed utility class per color combination

A typical Tailwind color system generates several shades per base color, say from 50 to 950, plus opacity modifiers like /50 or /75, each of which lands as its own CSS rule in the generated stylesheet. For a single theme that's manageable, but as soon as a project needs to support several brand themes, accent colors loaded dynamically from a database, or user-defined color schemes, the number of theoretically required combinations quickly grows to a point where pre-generating them all stops making sense.

Hover and focus states in particular, which are often defined as a slightly darkened or lightened variant of a base color, are a textbook example of this problem, since in theory every possible base color would need its own precisely matched hover shade prepared in advance. The CSS color-mix() function solves this fundamentally differently by computing the blend not at build time but at runtime in the browser, based on arbitrary input colors, including ones only set at runtime through CSS variables.

2. The CSS color-mix() function basics

The syntax of color-mix() follows the pattern color-mix(in <color-space>, <color1> <percentage1>, <color2> <percentage2>), where the color space determines how the interpolation between the two colors is computed, and the percentages specify how strongly each color contributes to the result. A call like color-mix(in oklch, blue 70%, white 30%) produces a version of blue lightened by thirty percent white, computed in the perceptually uniform oklch color space.

If the percentages are omitted, the browser defaults to an even fifty-fifty blend, and if only one percentage is given, the other is calculated automatically so the total adds up to one hundred percent. This flexibility makes color-mix() a versatile tool for both simple lightening or darkening and more elaborate, multi-step color calculations, without needing a separately computed, static color stored in the stylesheet for every variant.

3. Practical example: a hover state as an automatically darkened base color

A classic use case is a button whose hover color should automatically be a slightly darkened version of the base color, regardless of which specific color is set as the theme accent. Instead of generating a separate hover utility for every possible accent color, the base color is defined once as a CSS variable, and the hover color is computed from it at runtime with color-mix() by blending in a portion of black.

In the example below, a button's accent color is set through the CSS variable --brand-color, and the hover color results from a blend of eighty-five percent of that variable and fifteen percent black. If the base color changes, say because a different brand theme is active, the hover color adjusts automatically along with it, without recalculating or redeploying a single line of CSS.

.btn-brand {
  --brand-color: oklch(60% 0.15 250);
  background-color: var(--brand-color);
  color: white;
  transition: background-color 150ms ease-out;
}

.btn-brand:hover {
  background-color: color-mix(in oklch, var(--brand-color) 85%, black 15%);
}

.btn-brand:active {
  background-color: color-mix(in oklch, var(--brand-color) 70%, black 30%);
}

4. Transparency variants without a utility class per combination

Transparency levels can also be produced with color-mix() by blending a color with the keyword transparent, for example color-mix(in srgb, var(--brand-color) 40%, transparent) for a variant of the base color reduced to forty percent opacity. The result is functionally equivalent to Tailwind's opacity modifier syntax like /40, but it also works for colors that aren't known to the build process as a fixed utility class, only becoming available at runtime through a CSS variable.

This technique is especially valuable for design systems that need overlay colors, shadow tints, or border colors at several transparency levels of a single base color, without the build process needing to know in advance which exact percentages will ever be needed. Instead of maintaining a fixed list of transparency steps, any blend can be written directly in CSS, which noticeably shrinks the generated CSS footprint for arbitrary values or color values loaded dynamically from a backend.

5. Combining color-mix() with CSS variables for theme colors

The real payoff of color-mix() shows up once it's combined with CSS variables, since that lets a full color system emerge that reacts at runtime to a single or a handful of base variables. Instead of storing primary, hover, active, and disabled colors as separate static values, only the primary color is defined as a CSS variable, and every derived state is computed relative to it via color-mix().

For multi-tenant or multi-brand projects, which come up often in agency work, this brings a significant maintenance advantage: a new client with their own brand color scheme only needs a new assignment of the CSS variable in the root scope or in a theme-specific wrapper, while every derived hover, active, and transparency state is computed correctly and automatically, with no need to produce a separate CSS build with pre-generated color classes for each new client.

6. How Tailwind v4 uses color-mix() internally for opacity

Tailwind v4 already uses color-mix() internally to implement its opacity modifier syntax like bg-blue-500/50, as soon as a color is available as a CSS variable in the modern oklch format, because that lets transparency be computed consistently without generating a separate, static rule for every combination of color and opacity level. For developers, this means the familiar slash-modifier utility syntax already benefits under the hood from exactly the technique demonstrated manually in this article.

This is useful to know for understanding why custom, hand-written color-mix() calls slot in seamlessly next to generated Tailwind utilities instead of feeling like a foreign concept: both rely on the same underlying CSS function, Tailwind just automates it for its predefined utility classes, while custom CSS variables and bespoke color-mix() calls remain responsible for cases that go beyond the built-in color system, such as dynamic brand colors.

7. Color spaces in color-mix(): oklch versus srgb

The color space chosen inside color-mix() directly affects the visual result of a blend, because different color spaces compute intermediate values differently. A blend in the classic srgb space can produce a visible gray cast or unexpectedly desaturated in-between tones for certain color combinations, because srgb isn't a perceptually uniform color space and linear interpolation there doesn't match the intuitively expected visual blend.

The more modern oklch color space was purpose-built for perceptually uniform transitions and delivers noticeably more natural-looking intermediate colors for most blend operations, which is why it has become the default choice for hover darkening, gradients, and theme calculations in modern projects. For simple transparency blends using the transparent keyword, the color space matters less, but for genuine two-color blends it's worth deliberately choosing the right one.

8. Browser support for color-mix()

color-mix() is supported by all current versions of Chrome, Edge, Firefox, and Safari, with Safari support starting in version 16.2 while the Chromium-based browsers and Firefox had it available a bit earlier. For most production projects that no longer need to support very old browser versions, color-mix() is therefore already fully usable today without any special compatibility check being necessary.

Unlike text-wrap or @starting-style, missing support for color-mix() has no harmless automatic fallback, since a browser without support discards the entire declaration as invalid and keeps whatever value was previously declared or inherited instead. Anyone who genuinely needs to support very old browsers should therefore set a static fallback value for the same property before the color-mix() declaration, which more modern browsers will simply override afterward.

9. Best practices and limits of color-mix() in production

A solid practice is to reach for color-mix() specifically for derived states like hover, active, disabled, and transparency levels, while a design system's actual base colors stay explicitly and deliberately defined rather than also being derived through nested blends, which quickly turns confusing. A clear convention, for instance always fifteen percent black for hover and thirty percent black for active, keeps behavior consistent and predictable across the entire project.

One limit of color-mix() is that it's pure color computation and performs no automatic contrast check for accessibility, which means derived colors should still be manually checked for sufficient contrast against backgrounds or text colors despite being computed automatically. With very light or very dark base colors in particular, an automatically computed hover variant can unexpectedly clash with other elements on the page, so design reviews for color-mix()-based color systems deserve the same care as reviews of statically defined palettes.

10. Summary

11. FAQ: color-mix() in Tailwind at a glance