Herramientas · Color · Conversor de colores · Guías · Why a Color Rarely Survives the Trip From One Format to Another

Why a Color Rarely Survives the Trip From One Format to Another

5 min de lectura

A color rarely stays in the format it was born in. A designer picks a blue in a design file and hands over a hex code. A developer pastes it into CSS, then needs that same blue at 40% opacity for an overlay, which means rgba() - so the hex gets converted by hand, or looked up in whichever converter happens to be open in another tab. Later, someone wants a slightly darker version of that blue for a hover state, easier to reason about in hsl() (drop the lightness a few points) than in hex. By the time a color has passed through three or four of these conversions, it has usually drifted a little from where it started - not from a typo exactly, just the ordinary rounding of converting between color models, plus the occasional hand-done conversion that has a genuine mistake in it.

Every format is answering a different question

Hex is the format everyone recognizes and almost nobody thinks in - six or eight digits of base-16 that mean nothing to a person reading them cold. RGB is closer to what a screen is actually doing: red, green and blue channels, 0 to 255 each. HSL is closer to how a person describes a color out loud - "a bit darker," "more saturated" - because it separates hue, saturation and lightness into three independent numbers instead of mixing them into three channel values. OKLCH is the newest of the four, and it exists to fix something the other three share: none of them are perceptually uniform, so an equal numeric change in hue or lightness doesn't read as an equal visual change. A color scale built in HSL can look evenly spaced on paper and uneven on screen; OKLCH is built so the numbers and the perception actually agree.

OKLCH isn't a design-tool curiosity anymore

It's a native CSS color function now, usable directly in a stylesheet the same way rgb() or hsl() is - not just a display format sitting in a design-system spreadsheet. That matters here because it changes what a conversion mistake actually costs: a value that looks right in a design tool but doesn't survive being typed as a literal oklch() in CSS isn't usable yet, and the gap only shows up once someone tries to ship it.

Where the hand conversion actually breaks

Hex to RGB is arithmetic most people get wrong more often than they'd guess, because it's base-16 split into three pairs, not something anyone has memorized past a handful of common colors. HSL to RGB is worse - it's a real formula with hue-wedge cases, not something to do in your head, and a slightly-misremembered version of it produces a color that's close but not the one that was actually specified. The failure mode usually isn't a value that's obviously wrong. It's one channel off by four or five, which looks identical to a hex code sitting in a spec document and slightly, unmistakably different once it's on screen next to the color it was supposed to match.

One color moving through four formats on its way through a project A pipeline of four boxes connected by arrows: a hex code from a design tool, converted to rgba for a CSS overlay, converted to hsl for a lightness tweak, converted to oklch for a newer color scale. A note below the arrows says each hand conversion is a place for a digit to slip. #3b82f6 rgba() overlay hsl() hover oklch() each hand conversion is a place for a digit to slip a converter that keeps all four in sync removes the arithmetic entirely
The same color, needed in four places across one project. Every hand conversion between them is a fresh chance to introduce a small, real difference.

Alpha makes this worse, not better

Every one of the four formats can carry an alpha channel, and that's exactly where a manual conversion gets riskier, not safer - now there are two numbers to get right instead of one, the color and the opacity, and they don't fail independently. An rgba() built by eyeballing a hex plus a guessed opacity percentage is two separate approximations stacked on top of each other. A design system with a defined opacity scale (100%, 80%, 40%, and so on) only stays consistent if every color that uses it is converted the same way, every time, by the same process, not by whoever happened to be touching that file that week.

A slug outlives a redesign; a color outlives a rebrand

The actual cost of a slightly-off conversion is almost never visible on its own. It's visible when two elements that are supposed to share a color don't quite - one converted correctly, one converted by hand a few weeks earlier by someone working through hex-to-rgb math on a whiteboard. A palette expressed consistently across formats, always converted the same way, is the difference between a design system that reads as deliberate and one that quietly drifts, swatch by swatch, every time someone needs the "same" color in a format it wasn't originally specified in.

A color converter that keeps all four formats in sync, live, removes the actual point of failure: the arithmetic. Type or paste into any field and the other three update immediately, computed the same way every time, with the alpha channel carried through automatically instead of guessed at separately. The how-to guide walks through all four conversions in order, and if the reason you're reaching for a fourth format is specifically OKLCH, this guide covers what actually changes when a color scale moves to it.

Probar Conversor de colores gratis Conversor de colores