HSL

HSL is a color specification system that lets you pick colors by naming the hue in degrees around the color wheel, the saturation as a percentage, and the lightness as a percentage from 0 to 100. It was added to CSS in 2009 as a more intuitive alternative to RGB. The idea was simple. Designers think in terms of red or blue, vivid or dull, light or dark. HSL gave those concepts direct variables. Many early design systems built their entire color logic on top of it. Bootstrap 4 used HSL for all its theme colors. Shopify Polaris relied on it for their merchant dashboard components. You could change the hue for branding and the rest of the palette would update proportionally. At least that was the theory. For small projects it delivered. The syntax was clean and most code editors offered autocomplete for hsl values. It became the default language for CSS custom properties in thousands of codebases between 2015 and 2022. Tools like chroma.js and the original Tailwind color functions treated HSL as the primary model for mixing and shading. Bjorn Ottosson even referenced its shortcomings directly when he released OKLab in 2020 yet teams kept using it because the names felt right.

HSL is not a perceptually uniform system. This is the fatal flaw that the entire industry is still recovering from. The lightness value in HSL does not match human perception of lightness. A blue at 50 percent lightness looks much darker than a yellow at 50 percent lightness. This creates constant drift in palettes. HSL is not the solution to hex problems. It is a thin wrapper around the same sRGB math that caused those problems. It is not reliable for hue interpolation in gradients or animations. The path it takes often produces muddy or unexpected intermediate colors. It is not ready for the wide gamut world of P3 displays that most new devices support. The model was created long before modern display technology and it shows. Every time a design team complains that their color scales look inconsistent despite even steps they are describing an HSL problem. The names sounded right but the coordinate system was never calibrated to eyes. HSL is not the endpoint. It is a transitional format that outlived its usefulness the moment OKLCH shipped in browsers.

Concrete example. Take hsl(220, 70%, 50%) next to hsl(45, 70%, 50%). The first is a deep sky blue. The second is a bright golden yellow. According to HSL they share the same lightness. In reality the yellow appears much lighter and more luminous. This mismatch was baked into the default palettes of Tailwind CSS v3, Ant Design 4, and older versions of Material UI. One team at a Series B fintech company in 2023 audited their UI and found their primary blue at that HSL lightness contrasted differently with white than their accent orange at the same value. The contrast ratios varied by 0.8 points which broke their accessibility targets on hover states. They spent three days adjusting each color manually by eye. When they converted the same palette to OKLCH using identical L values the contrast became predictable and the visual weight evened out across all hues. Another example is in data viz. A chart using HSL hues for categories at the same saturation and lightness made the yellow bar dominate the visual hierarchy even though all bars represented equal data. Switching to OKLCH fixed the visual equality instantly. GitHub ran into identical issues in Primer where their accent colors required per hue overrides for dark mode. The same pattern repeated at Vercel until they updated their system.

Use HSL when you need to ship a quick prototype and browser support or team familiarity is a constraint. It works for marketing one pagers where the color palette is limited to three or four values and a designer can review every screen. Some legacy enterprise tools built before 2022 still use HSL successfully because their interfaces are simple and their users do not demand perfect dark mode. That is the extent of its useful territory in modern work.

Do not use HSL when building a scalable design system. Do not depend on it for products that require seamless light and dark modes because you will fight constant overrides for each hue family. Never choose HSL if you work on interfaces for modern hardware that supports P3 color because you are leaving vividness on the table. Stripe ran into these exact limitations when scaling their payment components and moved to perceptual systems in 2023. The Radix team adopted OKLCH principles for their color primitives to avoid the same issues. Linear rebuilt their entire UI color foundation on OKLCH after tracking dozens of lightness drift bugs. If your team is still debating why the orange 500 feels lighter than the blue 500 in production the answer is in the coordinate system. HSL is the reason those arguments exist. Replace it with OKLCH and those debates end. The audit becomes a table operation instead of an eye test. Your contrast scores stabilize. Your gradients look natural. The only teams still committed to HSL at scale are the ones that have not yet measured the maintenance cost.

HSL gave us the words without the accuracy and that is why it lost to OKLCH.