HEX vs RGB vs HSL vs OKLCH — Cuándo cada formato de color de CSS realmente tiene sentido

Abra cualquier base de código escrita por alguien que aprendió CSS en W3Schools en 2011 y encontrarás una pared de #rrggbb valores. HEX está por todas partes — no porque sea el formato más adecuado para el trabajo, sino porque era el formato en todos los tutoriales y los seleccionadores de colores cuando la mayoría de nosotros comenzamos a aprender CSS. Aún funciona. No se va a ir. Pero en 2026, usar HEX para todo es como escribir JavaScript sin const porque aprendiste de un blog de 2009.

Existen cuatro formatos de color que vale la pena conocer: HEX, RGB, HSL y OKLCH. Cada uno es la opción adecuada en situaciones específicas — y la mala opción en otras. Aquí está cuándo usar cuál.

HEX (#rrggbb / #rrggbbaa)

HEX codifica el color como pares de dígitos hexadecimales: dos para rojo, dos para verde, dos para azul. #ff5733 se traduce a rgb(255, 87, 51) — un rojo-amarillo. Sin un selector de color abierto, no puedes leer ese valor; simplemente tienes que saberlo.

Existe una abreviatura: #f53 se expande a #ff5533. Solo funciona cuando ambos dígitos en cada par son iguales. La transparencia es el cuarto par: #ff5733cc — donde cc es el canal de transparencia. Eso es aproximadamente 80% de opacidad para quienes están contando en casa (0xCC / 0xFF ≈ 0.8). Totalmente válido, completamente ilegible.

Cuándo HEX tiene sentido

• Tokens de diseño de Figma o Sketch. Los diseñadores exportan HEX. Lo pegan. Esa es la secuencia. No lo combatas.
• Cualquier lugar en el que el valor sea estático y los herramientas visuales lo controlen. Si un selector de color de VS Code o DevTools del navegador es lo que produce el valor, HEX está bien.
• Integraciones de terceros que solo aceptan entrada en HEX.

Cuándo HEX es una mala opción

• Modificar colores de forma programática — no puedes realizar cálculos razonables sobre #ff5733
• Expresar relaciones de tonalidad — no hay una forma intuitiva de derivar una variante más clara o más oscura
• Crear un sistema de diseño con tokens semánticos

RGB / RGBA

RGB especifica los mismos canales de rojo, verde y azul en decimales simples. rgb(255, 87, 51) es el mismo rojo-amarillo que #ff5733, pero los valores de canal son al menos números legibles para el ser humano. La sintaxis moderna del nivel 4 de colores en CSS elimina las comas: rgb(255 87 51). La transparencia se expresa con una barra: rgb(255 87 51 / 50%). La antigua rgba(255, 87, 51, 0.5) todavía funciona — los navegadores no la han eliminado y no la eliminarán.

Cuándo RGB tiene sentido

• Manipulación de colores en JavaScript. Cuando necesitas ajustar la brillo mediante mezcla con blanco: puedes realizar cálculos directos sobre los valores de canal.
• Canvas y WebGL. Las APIs trabajan con enteros de 0 a 255 o flotantes de 0 a 1. RGB se alinea directamente con lo que espera el flujo de píxeles subyacente.
• Cuando obtienes valores de canal desde un sensor de hardware o una biblioteca de imágenes y no necesitas convertirlos.

Cuándo RGB es una mala opción

• Diseñar esquemas de color — no existe un modelo mental visual para saber qué parece un pequeño ajuste en RGB
• Temas de modo oscuro — tendrías que recalcula los tres canales para cambiar la luminosidad

HSL (Tono / Saturación / Brillo)

HSL es el primer formato de color que se alinea con la forma en que los humanos piensan sobre el color. El tono es un ángulo en el reloj de colores (0–360°), la saturación controla la intensidad del color (0% = gris, 100% = puro) y el brillo controla la intensidad de luz (0% = negro, 100% = blanco). hsl(14 100% 60%) es ese mismo rojo-amarillo.

La ventaja práctica: si quieres una variante más oscura de un color, reduce el valor de brillo. Una versión más tenue? Reduce la saturación. Puedes derivar un conjunto completo de tonos a partir de un único valor de tono. Esta es la razón por la que los sistemas de propiedades personalizadas en CSS se basan en HSL:

:root {
  --brand-hue: 14;
  --brand-saturation: 100%;

  --brand-400: hsl(var(--brand-hue) var(--brand-saturation) 70%);
  --brand-500: hsl(var(--brand-hue) var(--brand-saturation) 60%);
  --brand-600: hsl(var(--brand-hue) var(--brand-saturation) 50%);
  --brand-700: hsl(var(--brand-hue) var(--brand-saturation) 40%);
}

La transparencia funciona de la misma manera que los demás: hsl(14 100% 60% / 50%).

Existe una limitación real con HSL: su escala de brillo no es perceptualmente uniforme. Dos colores con el mismo valor de L pueden parecer muy diferentes en brillo — prueba hsl(60 100% 50%) (amarillo) y hsl(240 100% 50%) (azul) lado a lado. El amarillo parece mucho más brillante, aunque comparten L=50%. Esto importa para el diseño accesible y especialmente para los gradientes.

Cuándo HSL tiene sentido

• Sistemas de color y tokens de diseño. El patrón de paleta de tono único descrito anteriormente es ergonómico y legible.
• Temas de modo oscuro. Intercambia los valores de L, mantén todo lo demás. Funciona de forma limpia.
• Tintes y tonos en propiedades personalizadas de CSS — el caso para el cual fue diseñado.

OKLCH — La sustitución moderna

OKLCH es lo que HSL debería haber sido. Describe el color en tres valores: Brillo (0–1), Croma (como saturación, aproximadamente 0–0.4) y Tono (0–360°). oklch(0.65 0.18 28) es aproximadamente el mismo rojo-amarillo.

La diferencia clave con respecto a HSL es la uniformidad perceptual. En OKLCH, dos colores con el mismo valor de L realmente parecen igualmente brillantes para el ojo humano. El amarillo en L=0.65 y el azul en L=0.65 parecerán tener una luminancia similar — en contraste con HSL, donde el amarillo domina. Esto importa de dos maneras específicas:

• Diseño accesible. Cuando calculas los ratios de contraste basados en valores de L, reflejan lo que los usuarios realmente perciben — no solo lo que dice la matemática.
• Gradients. Un gradiente en HSL desde azul hasta amarillo pasa por una banda gris turbia en el medio. El mismo gradiente en OKLCH permanece vibrante en todo momento porque los pasos intermedios mantienen una luminancia percibida constante.

Compatibilidad con navegadores en 2023: todos los navegadores modernos (Chrome 111+, Firefox 113+, Safari 15.4+). Sin soporte para IE11 — y nadie que esté desarrollando código nuevo en 2026 está dirigido a IE11.

Tailwind v4 movió toda su paleta de colores a OKLCH. Eso no es un detalle de implementación menor — es una señal del marco de CSS más ampliamente utilizado que esta es la dirección correcta para los sistemas de color.

Si estás construyendo o experimentando con gradientes en HSL o OKLCH, el Generador de degradado CSS en IO Tools soporta ambos formatos directamente — útil para ver la diferencia en la calidad del gradiente lado a lado.

Cuándo OKLCH tiene sentido

• Sistemas de diseño nuevos construidos desde cero. Si estás definiendo tus tokens de color hoy, OKLCH te da uniformidad perceptual que HSL no ofrece.
• Interfaces con muchos gradientes. La diferencia en la calidad del gradiente es visible y significativa.
• Paletas de colores accesibles donde necesitas ratios de contraste para reflejar la percepción visual real.

El mismo color en todos los cuatro formatos

Aquí está rgb(255, 87, 51) — un rojo-amarillo cálido — expresado en todos los formatos, con variantes de transparencia de 50%:

Formato	Color sólido	50% Transparente
MALEFICIO	#ff5733	#ff573380
RGB	rgb(255 87 51)	rgb(255 87 51 / 50%)
HSL	hsl(14 100% 60%)	hsl(14 100% 60% / 50%)
OKLCH	oklch(0.65 0.18 28)	oklch(0.65 0.18 28 / 50%)

Observa cuál sería la que elegirías editar manualmente si necesitara hacer el color 20% más oscuro. HEX: abrirías un selector de color. RGB: harías cálculos sobre tres valores. HSL: cambiarías el valor de L de 60% a 40%. OKLCH: cambiarías el valor de L de 0.65 a 0.45. Las versiones de HSL y OKLCH expresan directamente la intención.

El camino práctico de migración

No vayas a refactorizar tus valores HEX existentes. Funcionan, no están rotos, y el retorno sobre la inversión de ese cambio es prácticamente cero. Déjalos.

Para nuevos proyectos, aplica estas reglas:

• Colores estáticos provenientes de un diseñador o herramienta de diseño → HEX. Pega lo que te da Figma. No necesitas conversión.
• Colores que manipulas en JavaScript o que pasas a canvas/WebGL → RGB. La aritmética basada en canales se alinea directamente.
• Nuevas propiedades personalizadas de CSS y tokens de diseño → HSL o OKLCH. Quieres la capacidad de derivar tonos y sombras sin recalcula tres valores separados.
• Nuevos sistemas de diseño desde cero, o trabajos con muchos gradientes → OKLCH. La uniformidad perceptual vale la curva de aprendizaje ligera para los valores de Croma.

Un patrón concreto para propiedades personalizadas de CSS en un nuevo proyecto:

:root {
  /* Define the base in OKLCH */
  --brand: oklch(0.65 0.18 28);

  /* Derive tonal variants by adjusting L */
  --brand-light: oklch(0.78 0.14 28);
  --brand-dark:  oklch(0.48 0.20 28);
  --brand-muted: oklch(0.65 0.08 28);

  /* Transparency with the slash syntax */
  --brand-ghost: oklch(0.65 0.18 28 / 15%);
}

Este es legible, editable sin herramientas y produce gradientes mejores que el enfoque equivalente en HSL.

En pocas palabras

HEX no está mal — simplemente es especializado. Está optimizado para valores que obtienes de herramientas visuales y que pegas en el código, no para valores que piensas o modificas. RGB es útil cuando necesitas interactuar con APIs de JavaScript o canvas. HSL sigue siendo una buena opción para tokens de diseño si trabajas en un código existente que lo utiliza. OKLCH es donde deberías llegar para nuevos sistemas de diseño.

La barrera para adoptar HSL o OKLCH es menor de lo que parece. No necesitas migrar nada — simplemente comienza a usarlos para el siguiente conjunto de tokens que escribas. El Selector de color en IO Tools muestra cualquier color en todos los cuatro formatos simultáneamente, lo cual es una referencia útil cuando estás convirtiendo valores HEX existentes a HSL o OKLCH para un nuevo token.

También te puede interesar