CSS color-mix() and OKLCH: Build Brand Color Variants with Tested Fallbacks

sRGB is a widely used RGB color space on the web. HSL is a way to manipulate RGB colors through hue, saturation, and lightness, but equal HSL lightness does not imply equal perceived brightness.

For example, hsl(60 100% 50%) and hsl(240 100% 50%) have the same HSL lightness and very different relative luminance. HSL's lightness comes from the largest and smallest RGB components; it is not a perceptually uniform measure.

CIELAB and Oklab aim to make perceptual differences easier to work with. Björn Ottosson published Oklab in 2020; OKLCH is its polar-coordinate representation. Perceptual uniformity is an approximation, not perfect agreement for all colors and viewing conditions.

OKLCH expresses Oklab through three components:

• L, lightness: commonly written from 0 to 1 or as a percentage.
• C, chroma: zero is achromatic. The often-used value 0.4 is not a specification maximum; the displayable range depends on lightness, hue, and target gamut.
• H, hue: an angle around the hue circle, often expressed in degrees.

oklch(62.3% 0.214 259.815)
oklch(0.623 0.214 259.815)

These are two notations for the same color, used for Tailwind v4's blue-500. Oklab aims to improve perceptual behavior, including in blue regions, and can represent colors beyond sRGB. That does not mean every display can reproduce every OKLCH value.

Keeping L consistent can help coordinate colors with different hues. However, OKLCH L is not WCAG relative luminance. Contrast against the actual background still needs a separate calculation.

The examples here specify a color space and two colors. Omitted percentages, percentage normalization, and alpha all affect the result.

color-mix(in srgb, red 50%, blue)
color-mix(in oklch, #2563eb 80%, white)
color-mix(in oklch, #2563eb, black 30%)
color-mix(in oklch longer hue, red, blue)

The first three examples mix 50:50, 80:20, and 70:30 respectively. In polar color spaces, hue interpolation can follow different paths, such as shorter hue and longer hue. OKLCH does not guarantee that every mix matches the designer's intention or avoids every muted intermediate color.

Mixing with transparency changes alpha. The visible result then depends on compositing with the background. Out-of-gamut values may also be mapped when displayed, so inspect the actual output rather than assuming the notation alone guarantees a particular appearance.

A custom property can provide the input for several variants:

:root {
  --brand: #2563eb;
  --brand-hover: color-mix(in oklch, var(--brand), white 15%);
  --brand-active: color-mix(in oklch, var(--brand), black 15%);
  --brand-disabled: color-mix(in oklch, var(--brand), transparent 60%);
  --brand-border: color-mix(in oklch, var(--brand), white 70%);
  --brand-bg: color-mix(in oklch, var(--brand), white 92%);
  --brand-focus: color-mix(in oklch, var(--brand), transparent 70%);
}
.button {
  background: var(--brand);
  border: 1px solid var(--brand-border);
}
.button:hover { background: var(--brand-hover); }
.button:active { background: var(--brand-active); }
.button:disabled { background: var(--brand-disabled); }

Changing --brand updates the relationships. This is a color-generation example, not an accessibility-tested finished palette. If the button has white text, lightening its hover background may reduce the text's contrast.

Check focus indicators and borders against their actual adjacent colors too. Inactive controls have WCAG exceptions, but their state should still be understandable. A generated token is a candidate to test, not a pass result.

You can select a small set of base colors for each theme and share the relationships:

:root {
  --text: #1f2937;
  --bg: #ffffff;
  --accent: #2563eb;
}
[data-theme="dark"] {
  --text: #e5e7eb;
  --bg: #111827;
  --accent: color-mix(in oklch, #60a5fa, transparent 0%);
}
.card {
  background: color-mix(in oklch, var(--bg), var(--accent) 5%);
  border-color: color-mix(in oklch, var(--text), transparent 85%);
}

The dark theme explicitly chooses another accent. Mixing with transparent 0% preserves that input color; it does not invert lightness.

Sharing formulas reduces duplicated definitions, but it does not preserve every semantic role automatically. Review text, links, state changes, and translucent borders in both themes.

MDN compatibility data checked on September 5, 2026 lists basic oklch() support from Chrome/Edge 111, Firefox 113, and Safari 15.4. Two-color color-mix() is listed from Chrome/Edge 111, Firefox 113, and Safari 16.2. Relative colors and newer extensions require separate checks. These version numbers are not a measured audience-support percentage.

Custom properties can retain token sequences containing a function that is not supported as a color. Repeating a variable declaration with a static value first does not necessarily restore that earlier value when the later value fails at computed-value time. Use feature detection around the update:

:root { --brand-hover: #3b7ced; }
@supports (color: color-mix(in oklch, red, blue)) {
  :root { --brand-hover: color-mix(in oklch, #2563eb, white 15%); }
}
.button:hover { background-color: var(--brand-hover); }

The static value is a fallback color, not a promise of an exact match to the computed mix. Test both variants with their text and background. Passing a support query also does not prove the absence of browser-specific rendering differences.

Tailwind CSS v4's official palette uses OKLCH, including --color-blue-500: oklch(62.3% 0.214 259.815). It is inaccurate to characterize the entire v3 default palette as HSL-based.

Built-in colors still need to be evaluated in their actual foreground, background, and state combinations. Using OKLCH does not by itself guarantee wide-gamut output or accessibility.

1. Define the brand color in OKLCH or convert a known input color.
2. Express candidate variants with color-mix().
3. Use consistent lightness where useful, while remembering that L is not a contrast ratio.
4. For regular text at WCAG AA, check the 4.5:1 requirement where applicable and account for the criterion's exceptions.
5. Choose base colors for both themes and verify all resulting pairs.
6. Define static fallback values, then update custom properties inside @supports.
7. Name tokens by their role, such as --text-muted or --brand-hover, so their purpose is reviewable.

Color generation and validation belong in the same workflow. Neither a modern syntax nor a popular palette substitutes for checking the rendered interface.

• OKLCH describes lightness, chroma, and hue with an approximate perceptual model.
• color-mix() shares formulas for variants; it does not guarantee a contrast pass.
• Check percentages, hue paths, alpha, backgrounds, and gamut separately.
• Use @supports to separate custom-property fallbacks from computed colors.
• Distinguish basic syntax from newer features and verify both light and dark themes.