The same color, four ways of writing it
You write #84cc16 in your stylesheet. The browser reads it as rgb(132, 204, 22). The designer sent it from Figma as oklch(78% 0.18 130). Your accessibility tool says the contrast is borderline.
It is the same lime green every time. The notation just keeps changing depending on who is talking. Each one is good at a different job, and most stylesheets in 2026 still treat them like they are interchangeable. They are not.
Think of it like measuring distance. Meters and feet measure the same thing, but you would not put a footrace finish line at “2 kilometers” and report the winner’s stride in millimeters. Same here. Each color notation answers a different question.
Hex and RGB: the way the screen actually sees the color
A screen mixes three lights to make any color: red, green, blue. Hex and RGB tell it how much of each. #84cc16 means “this much red, this much green, this much blue”, written as a single short string.
color: #84cc16;
color: rgb(132 204 22);
color: rgb(132 204 22 / 0.8);Hex is what you store in design tokens, copy from Figma, and paste into Slack. RGB is what you write when you also need transparency. If you only need the round trip between the two, the hex to RGB converter does it in your browser without firing up a full picker.
Neither helps if the question is “make this color 10 percent darker”. You can darken hex by hand, but the result almost never looks 10 percent darker, because hex describes light, not how the eye reads it.
HSL: feels intuitive, will betray you
HSL splits a color into three knobs you can imagine: hue (which color), saturation (how vivid), lightness (how bright). Designers love it for ten seconds, then start a tonal scale and watch it fall apart.
hsl(82 78% 44%); /* the same lime as #84cc16 */
hsl(220 78% 44%); /* a blue with the SAME math, but visibly darker */Both lines have lightness 44%. Your eye sees the lime as bright, the blue as much darker. The math says they are equal. The math is wrong about how human eyes work.
For a one off “this red, but a bit lighter”, HSL is fine. For a design system where a button needs the same brightness across hover, focus, error and success, HSL will give you uneven steps and your designer will be very polite about asking why. The hex to HSL converter is enough when you just want to nudge a single token.
OKLCH: HSL that matches your eyeballs
OKLCH is the new one in CSS, supported in every browser since 2023. Same idea as HSL (lightness, chroma, hue), but the math actually matches how humans see brightness.
oklch(78% 0.18 130); /* the same lime as #84cc16 */
oklch(78% 0.18 250); /* same brightness, blue instead of lime */
oklch(50% 0.18 130); /* same lime, half as bright */The trick: pick a brightness, lock it, sweep through colors. Every color in the sweep looks equally bright to the human eye. That is what you have always wanted from your accent palette and never quite got.
Tailwind 4 ships its default colors in OKLCH. Adobe is moving its picker to OKLCH. If you build a design system in 2026 with anything else, your accent colors will drift and you will not know why.
The tradeoff is none of your downstream tools speak OKLCH yet. Most CMS color pickers, brand guides and stakeholder PDFs want hex. So you design in OKLCH and export to hex. The color converter on AldeaCode does that round trip live, in the browser, no upload.
What about contrast and accessibility?
Two colors can be exactly as bright as each other in OKLCH, and the WCAG contrast checker still says one combination passes and the other fails. That is because contrast tools measure something slightly different from “how bright did this look”.
For now: design with OKLCH so your colors stay coherent, but always run the actual final pairing through a contrast checker before you ship. The two tools do not contradict each other, they answer different questions.
A new contrast model called APCA is coming and it agrees more with what humans actually read. Once it is the default, OKLCH and the contrast check will line up better. Until then, keep using both.
A practical workflow
Pick brand and accent colors in OKLCH. Lock the brightness, change hue and saturation to make your tonal scale. Export to hex for everything else (Figma, design tokens, the brand book your client will email you).
Use HSL only for quick tweaks where exact perceptual match does not matter. Use plain RGB when you need an alpha (transparency).
Reach for the color converter to bridge a third party design and your stylesheet, the hash generator when you version the palette as a content hash, and the JSON formatter for the design tokens file you ship to the client. Browsers parse OKLCH natively today, so the only reason not to write it directly in CSS is your build chain stripping it. If that is the case, the build chain is the problem and not the color.