Pull up any CSS file with more than a few colors in it and you'll probably find all three formats mixed together, sometimes in the same component. That's not necessarily sloppy — it's usually just three different tools showing up at three different moments. The short version, if you want it before the explanation: HEX for colors you're just storing, HSL for colors you're actively adjusting, RGB for colors that came out of an image or a canvas. Here's why.
RGB is just how the screen actually works
Red, green, blue — three channels of light, each on a 0-255 scale, added together. That's not a design convention, it's literally what a pixel is made of, which is why RGB is the native output of nearly every tool that reads color straight from an image or a canvas element. A pure red is rgb(255, 0, 0), and cranking all three channels to full gives you white.
You'll rarely pick RGB values on purpose. You'll mostly encounter them already picked for you — a design handoff file, an eyedropper tool, a JavaScript library that extracts colors from a photo.
HEX is RGB wearing a shorter costume
There's no new information in a HEX code — it's the same RGB numbers, just rewritten in base-16 and squeezed into six characters behind a #. So rgb(37, 99, 235) becomes #2563EB, same color, fewer characters.
That compactness is exactly why it's the default output of nearly every color picker and design tool. It's also why it's basically unreadable — hand someone #2563EB cold and nobody can tell you if that's a light blue or a dark one without opening a picker first.
HSL is the one that actually thinks like you do
Hue, saturation, lightness. Hue is the color itself, a position on the wheel from 0 to 360 degrees. Saturation is how intense it is, 0% being gray and 100% being fully vivid. Lightness is how close it sits to black or white. Written out it looks like hsl(221, 83%, 53%), and unlike the other two, this one maps almost exactly to how a person would actually describe a color out loud.
The real payoff shows up the moment you need a variation of a color instead of just the color itself. Need a darker hover state? Drop the lightness number. Need a muted, disabled version? Drop the saturation. Nothing else has to change, and you're not guessing at new hex digits hoping they land somewhere close.
Laid out side by side
| Factor | RGB | HEX | HSL |
|---|---|---|---|
| Human readability | Low | Lowest | Highest |
| Easy to hand-edit | No | No | Yes |
| Compactness | Medium | Highest | Medium |
| Supports transparency | Yes (RGBA) | Yes (8-digit HEX) | Yes (HSLA) |
| Best for generated color scales | No | No | Yes |
| Default output of most tools | Sometimes | Usually | Rarely |
Where each one actually earns its place
RGB belongs wherever you're already pulling raw pixel data — reading a value off a canvas, working with a color-extraction library, or matching a spec that a designer exported directly from an image. HEX belongs in style guides and static references: the six brand colors that live in your design system doc and aren't going to be programmatically lightened or darkened. It's short, it pastes cleanly between Figma and code, and there's no real upside to using anything else for a value that never changes.
HSL earns its place the second a color needs to become multiple colors — a default, a hover, an active, a disabled state, a full 50-to-900 tint-and-shade scale. Every one of those is a lightness or saturation tweak away from the base value, which is exactly the kind of math HSL was built for and HEX actively fights against. This is also why PalettIQ's HSL panel exists as a dedicated slider set instead of just a HEX input — once you're adjusting rather than just storing, sliders beat guessing new hex digits every time.
There's a middle case worth mentioning too: some teams keep HEX as the source of truth in their design tokens file purely because it's what designers hand off from Figma, then convert to HSL only inside the code that actually generates variants. Neither approach is wrong — it comes down to whether your bottleneck is designer-developer handoff (favor HEX) or programmatic color generation (favor HSL).
What that actually looks like
Say your brand color is hsl(221, 83%, 53%). Instead of hand-picking four unrelated HEX values for a hover state, a disabled state, and a light background tint, you're changing one number each time:
- Default:
hsl(221, 83%, 53%) - Hover:
hsl(221, 83%, 45%) - Light background:
hsl(221, 83%, 95%) - Disabled:
hsl(221, 20%, 60%)
Same hue running through all four, so the set still reads as one color family at a glance — something that's surprisingly hard to guarantee when you're hand-picking HEX values one at a time and eyeballing whether they "feel" related.
A couple of formats you'll bump into eventually
RGBA and HSLA are the base formats with a fourth number for opacity tacked on, 0 for invisible and 1 for solid — reach for these for overlays, shadows, or anything translucent. CMYK is the odd one out here since it's built for ink on paper, not light on a screen; if a design is heading to a printer, it needs converting, because colors genuinely shift between a monitor and a printed page.
OKLCH is the newer one worth keeping an eye on. HSL has a real flaw — two colors with the same lightness value can look noticeably different in actual brightness depending on hue. OKLCH fixes that, so equal lightness genuinely looks equally bright, which matters a lot for generating accessible scales programmatically. Browser and tooling support is still catching up, so it's not a default yet, but it's headed that way.
You don't need to do the math yourself
All three formats describe the exact same color space, so converting between them changes nothing about the actual color, only how it's written — and nobody does this conversion by hand anymore. Browser dev tools let you click a swatch in the inspector and cycle through formats. Figma switches the input field with one click. Any decent color picker handles it instantly as you drag a slider.
Where people usually trip up
- Manually guessing a lighter or darker HEX value instead of adjusting lightness in HSL — this rarely lands where you expect it to.
- Mixing formats across a codebase with no real convention, which turns theming or a find-and-replace refactor into a headache later.
- Reaching for plain RGB when you actually need transparency, then getting confused when opacity doesn't behave the way you expected.
- Treating HEX and RGB as if they're different colors — they're not, converting between them is purely cosmetic.
- Building an entire design token system on HEX and then fighting it later when dark mode or a theming feature needs generated variants.
Questions people actually ask about this
So which one should I actually default to?
If you're just storing a static brand color, HEX. If you're building anything that needs lighter or darker versions of that color — buttons, themes, states — HSL. RGB mostly shows up when you're pulling a value from an image or a canvas, not something you'd choose from scratch.
Wait, is HEX literally the same color as RGB?
Yes, exactly the same, just written differently. #2563EB and rgb(37, 99, 235) are the identical color — one's in base-16, one's in base-10. Converting between them changes nothing about how the color actually looks.
Why does everyone say HSL is better if HEX is what most tools show me?
Because most tools are optimized for storing a color, not editing it. HEX is great once you've already picked the color. HSL is better while you're still deciding, since you can drag a lightness slider and get a predictable result instead of guessing new hex digits.
What's the deal with RGBA and HSLA then?
Same formats, just with a fourth number tacked on for opacity, 0 for invisible and 1 for fully solid. If you need a translucent overlay or a soft shadow, that's when you reach for these instead of the plain versions.
Do I need to memorize how to convert between them?
No, and honestly nobody does this by hand day to day. Browser dev tools, Figma, and basically every color tool let you click a swatch and cycle between formats instantly.
Is it worth learning OKLCH right now?
Worth knowing about, not worth switching to yet unless you have a specific reason. Browser support and tooling are still catching up, so for most day-to-day work HSL still gets you 90% of the benefit with a lot less friction.
Why do some hex codes have 8 characters instead of 6?
The extra two characters add an alpha channel for transparency, the same thing RGBA and HSLA do with a fourth number. So #2563EBCC is the same blue as #2563EB, just at roughly 80% opacity.
Pick based on the job, not habit
None of these formats are "wrong" — they're the same colors wearing different outfits for different situations. The mistake isn't using all three in one project, it's using whichever one you're used to without thinking about whether it actually fits the job in front of you. Store it in HEX, generate variations of it in HSL, and let RGB show up when it shows up on its own.