HSL vs HSV vs HWB: Which Color Model Actually Belongs in Your CSS and Design Workflow

If you've ever set a color in Figma and then tried to match it in CSS, you've probably brushed up against all three: the HSL sliders in the browser inspector, the HSB (HSV) panel in Figma, and the newer HWB syntax quietly sitting in the CSS Color Level 4 spec. They all start with a hue angle. They're all supposed to describe the same color. Yet they give you completely different numbers for exactly the same shade, and switching between them mid-project is a reliable source of subtle mismatches.

This guide cuts through the confusion — what each model actually encodes, where its strengths and blind spots are, and which one to use where in 2026.

The Core Difference: What the Second and Third Sliders Actually Mean

All three models share the same first axis: hue, a 0–360° wheel where 0° = red, 120° = green, 240° = blue. The difference lies entirely in how they describe the remaining two dimensions of a color.

HSL (hue, saturation, lightness) is the model CSS has shipped since CSS3. Lightness runs from 0% (pure black) to 100% (pure white), with 50% landing on the most vivid version of the hue. Saturation controls how colorful versus grey the output is. The mental model is: "I want a medium-bright blue, 70% saturated" — and L=50% gives you that peak vividness.

HSV (hue, saturation, value) — also called HSB in Adobe and Figma — uses "value" instead of lightness. Value runs from 0% (black) to 100% (the full hue, not white). Saturation controls the mix of the pure hue with white. The mental model here is: "I'm mixing paint — start from the pure pigment, then add white or dilute the intensity." Illustrators and photographers tend to find HSV more intuitive because darkening a color (lowering V) feels like adding shadow, not crossing through a grey midpoint.

HWB (hue, whiteness, blackness) is the newest of the three and was standardized in CSS Color Level 4. It makes the mixing analogy explicit: whiteness is how much white paint you're adding, and blackness is how much black. The two axes are independent. When whiteness + blackness add up to 100%, you get a pure grey regardless of hue, which makes the math predictable and the sliders very easy to reason about.

A Real Conversion to See the Difference

Take a steel-blue color: hsl(200, 80%, 50%). The three representations of the same pixel are:

HSL  →  hsl(200, 80%, 50%)
HSV  →  hsv(200, 89%, 90%)
HWB  →  hwb(200 10% 10%)

The hue stays at 200° across all three. But look at what changes:

• In HSL, saturation 80% at lightness 50% gives a vivid mid-tone.
• In HSV, the same color reads as 89% saturated at 90% value — both numbers are high, suggesting a bright, punchy shade.
• In HWB, the same color is simply "10% white, 10% black added to the pure hue" — you can see immediately that equal white and black amounts give a balanced, medium-intensity result.

You can verify this with Toolora's Color Converter, which converts between HEX, RGB, HSL, HSV, and CMYK in real time. Paste #1AA3E6 (the RGB approximation of that steel blue) and you'll see all five representations update simultaneously.

CSS Support in 2026 — HWB Is Fully Usable

When I first encountered HWB syntax, I assumed it was experimental. I went to check caniuse, and was surprised: hwb() landed in Firefox 96 (January 2022), Safari 15 (September 2021), and Chrome 101 (April 2022). As of mid-2026 those browsers collectively cover more than 96% of global web traffic (per Statcounter's browser share data), which puts HWB firmly in "use it without a fallback" territory for most projects.

The CSS syntax is clean:

/* CSS Color Level 4 syntax */
background-color: hwb(200 10% 10%);

/* Equivalent HSL */
background-color: hsl(200, 80%, 50%);

Both lines produce the same rendered pixel. The HWB version is often easier to edit by hand because the two remaining sliders have clear semantic meaning — you're literally specifying how much white and black are mixed in.

When to Use Each Model

Use HSL when writing CSS by hand. It's the established CSS model, it's what the browser inspector gives you, and Tailwind, shadcn, and most CSS design systems express their palettes in HSL. Keeping lightness at 50% while sweeping saturation is the quickest way to build a tint/shade scale. The CSS Color Format Converter on Toolora outputs HSL alongside Tailwind class names and CSS custom property declarations, which saves several copy-paste steps when you're building a token system.

Use HSV when working in design tools. Figma, Photoshop, Sketch, and Affinity all default to HSB/HSV. The value slider directly controls perceived brightness in a way that matches how artists think about light. If you're specifying a "light hover state" of a button, lowering value from 90% to 70% is more predictable than nudging HSL's lightness, which changes both the saturation and the apparent brightness simultaneously due to the bicone geometry.

Use HWB when you need predictable tint/shade arithmetic. Because white and black are explicit axes, hwb(30 20% 0%) and hwb(30 0% 20%) are perceptually symmetric (a tint and a shade of orange at the same "distance" from the pure hue). I tested this when building a button-state scale for an orange primary: fixing W+B to 20% while shifting the ratio gave a clean progression from near-white to near-black with no unexpected grey-shifts that HSL sometimes introduces around the 50% lightness boundary.

The One Case Where None of Them Is Enough

None of HSL, HSV, or HWB is perceptually uniform. That is, a 10° hue rotation at H=30° looks very different from a 10° rotation at H=200° — yellow-to-orange is visually huge; blue-to-cyan barely registers. If you need colors that are equidistant in human perception (accessibility checks, gradient harmony, chart palette generation), OKLCH is the right model. OKLCH's L axis is calibrated to match how the human visual system actually responds to lightness changes, so equal numerical steps produce equal perceptual steps.

For that work, Toolora's OKLCH tool handles the conversion, but the decision of which model to open first still comes down to workflow context: CSS tokens → HSL, design-tool sliders → HSV, hand-tuned tints → HWB, perceptual accuracy → OKLCH.

Summary

| Model | CSS native | Design tool native | Intuition | |-------|-----------|-------------------|-----------| | HSL | ✓ (CSS3) | Rarely | Lightness pole | | HSV | No (use JS) | ✓ Figma/PS | Paint mixing | | HWB | ✓ (CSS4, 96%+ browser support) | Rarely | White + Black explicit |

The right model is the one that makes the edit obvious. For CSS properties, HSL or HWB saves you from mental translation. For Figma components, HSV already matches the panel in front of you. And for critical accessibility or palette work, move up to OKLCH.

---

Made by Toolora · Updated 2026-06-28