CSS color-mix() Playground — Free HTML CSS JS Snippet

Blending two colors used to be something CSS genuinely could not do on its own — you either pre-computed the blended hex value in a design tool and hard-coded it, or you reached for a preprocessor function like Sass's mix(), or you wrote JavaScript to interpolate RGB channels manually. The color-mix() function, part of the CSS Color Module Level 5 and supported in Chrome/Edge 111+, Safari 16.2+, and Firefox 113+ (full baseline coverage across evergreen browsers since mid-2023), makes color blending a first-class native CSS operation you can use directly in any property that accepts a color — background, border, box-shadow, even inside another color-mix() call.

How color-mix() works technically

The syntax is color-mix(in <color-space>, <color> [<percentage>], <color> [<percentage>]). The first argument names the color space the interpolation happens in — this demo lets you switch between oklch, oklab, srgb, hsl, and lch live so you can see how dramatically the choice of space changes the result. The two colors that follow can each carry an optional percentage; if you specify a percentage on only one color, the other is inferred as the remainder needed to reach 100%, and if you omit both, the browser splits 50/50. This demo always supplies the first percentage explicitly (driven by the slider) and lets the second color's share be implied, exactly matching how color-mix(in oklch, var(--color-a) 30%, var(--color-b)) is typically written in real stylesheets.

Why color space choice actually matters

This is the part most developers new to color-mix() underestimate. Mixing in srgb (the classic RGB channel-averaging approach, similar to what rgba() blending or most JS color libraries default to) frequently produces muddy, desaturated midpoints when the two input colors are far apart on the color wheel — mixing a saturated blue and a saturated pink in sRGB often passes through a grayish-purple dead zone. Mixing in oklch or oklab — perceptually uniform color spaces designed so that equal numeric steps look like equal visual steps to the human eye — produces much more vivid, visually pleasing gradients between the same two endpoints, because the interpolation path follows how humans actually perceive hue and lightness rather than raw channel math. This is exactly why modern CSS color tooling (and this demo) defaults to oklch: it is widely considered the best general-purpose choice for UI color blending in 2025/2026 work, particularly for building tints, shades, and hover-state variants of a brand color programmatically.

Why this matters for modern UI development

Before color-mix(), generating a lighter or darker variant of a brand color (for hover states, disabled states, or a tint scale) required either a Sass build step, a JavaScript color library shipped to the client, or manually authored hex values for every shade — none of which could respond to a CSS custom property changing at runtime. With color-mix(), you can write background: color-mix(in oklch, var(--brand-color) 85%, white) directly in a stylesheet and get a computed 15%-lightened tint that automatically updates if --brand-color changes (for example, via a theme switcher or user-customizable accent color), with zero JavaScript recomputation needed at all.

How this demo wires it together

The two <input type="color"> pickers and the range slider don't compute any color math themselves — every change handler simply builds a literal color-mix(in <space>, <colorA> <ratio>%, <colorB>) string and hands it to document.documentElement.style.setProperty('--mixed-color', mixFunction). The actual pixel-level blending happens entirely inside the browser's rendering engine when it resolves that custom property against .swatch-result { background: var(--mixed-color, ...); }. This is the idiomatic way to make CSS color functions interactive: pass strings into custom properties, and let CSS do the computation.