Formatos de color CSS: hex, RGB, HSL, OKLCH — cuándo usar cada uno

El CSS moderno admite cuatro notaciones de color principales: hex (#FF6600), rgb(),hsl() y el más nuevo oklch(). Todas describen la misma gama de color (sRGB por defecto, más amplia para OKLCH). Difieren en legibilidad humana, facilidad de manipulación y qué tipo de cambio de color se siente natural.

Los cuatro formatos de un vistazo

Hex: el formato de almacenamiento

Hex codifica cada canal RGB como un valor hexadecimal de dos dígitos. #FF6600 significa rojo 255, verde 102, azul 0 — ese es un naranja vivo.

Ventajas: corto, universalmente comprendido, fácil de copiar y pegar, funciona en cualquier contexto CSS.

Desventajas: opaco para leer (“¿es #7E4F2Bun tono cálido o frío?”), no se puede ajustar fácilmente la luminosidad o saturación sin convertir primero.

El CSS moderno admite hex de 8 dígitos para la transparencia:#FF6600AA es el naranja anterior con 67% de opacidad (AA = 170 / 255).

rgb(): el formato de canal explícito

Los mismos canales que hex, números decimales, alfa opcional. Coexisten dos sintaxis:

• Forma de coma heredada: rgb(255, 102, 0) o con alfa rgba(255, 102, 0, 0.67)
• Forma moderna con espacios: rgb(255 102 0) o con alfa rgb(255 102 0 / 0.67)

Mejor para la generación programática: construir color a partir de la salida del algoritmo, mezclar dos colores, calcular el contraste de accesibilidad.

hsl(): el formato ajustable por humanos

Tres valores: tono (0-360°),saturación (0-100%),luminosidad (0-100%). Ajustar cada uno de forma independiente se siente más natural que modificar los canales RGB.

• Tono: el color en sí. 0 = rojo, 60 = amarillo, 120 = verde, 180 = cian, 240 = azul, 300 = magenta.
• Saturación: 0% = gris, 100% = color puro.
• Luminosidad: 0% = negro, 50% = tono puro, 100% = blanco.

Mejor para: tokens de diseño donde quieres una variante del “mismo color, más oscuro” — reduce la luminosidad un 10%, mantén el tono y la saturación. Los estados hover, variantes de tema y gradientes se benefician.

El problema: la luminosidad de HSL no sigue el brillo percibido uniformemente. El amarillo HSL al 50% de luminosidad parece mucho más claro que el azul HSL al 50% de luminosidad. Para el diseño de color perceptualmente uniforme, OKLCH es la mejor elección.

oklch(): el formato perceptual

Tres valores: L (luminosidad, 0-1),C (croma, 0-~0.4 para sRGB visualizable),H (tono, 0-360°). Basado en el espacio de color perceptual OKLab (Björn Ottosson, 2020).

La propiedad clave: los valores de luminosidad iguales parecen igualmente brillantes. oklch(0.6 0.2 0) (rojo) yoklch(0.6 0.2 120) (verde) yoklch(0.6 0.2 240) (azul) tienen todos el mismo brillo percibido, a diferencia de HSL donde estos variarían dramáticamente.

Mejor para: diseñar escalas de color, temas de modo oscuro, asegurar que el contraste del texto se mantiene en una rotación de tono. Compatible con todos los navegadores evergreen desde 2023.

El problema: el croma alcanza su máximo en diferentes valores por tono. El azul de alto croma es alcanzable; el amarillo de alto croma llega antes a los límites de la gama sRGB. Usa un valor de croma que el navegador pueda renderizar en todos los tonos que necesites, o acepta el recorte en los extremos.

Elegir el correcto

• Para colores de marca y tokens de diseño:define en HSL o OKLCH; eso es lo que los diseñadores pueden ajustar de manera significativa. Almacena hex como respaldo en archivos heredados.
• Para rampas de color de UI (50/100/200/.../900):OKLCH con un croma fijo y luminosidad variable produce escalas perceptualmente uniformes. HSL funciona pero el espaciado visual es desigual.
• Para copiar desde una especificación de Figma/Photoshop:pega hex. Convierte a través de nuestra herramienta hex a RGB o un preprocesador CSS cuando necesites manipular.
• Para elecciones impulsadas por accesibilidad:calcula el contraste WCAG en la forma rgb. La fórmula de contraste opera en RGB lineal, no directamente en hex o HSL.

El patrón de propiedad personalizada CSS

Las arquitecturas de tema modernas almacenan colores como propiedades personalizadas HSL/OKLCH para que puedan derivarse:

:root {
  --primary-hue: 24;
  --primary: oklch(0.72 0.18 var(--primary-hue));
  --primary-hover: oklch(0.65 0.18 var(--primary-hue));
  --primary-bg: oklch(0.92 0.05 var(--primary-hue));
}

Cambiar el tono una vez rota toda la paleta de forma consistente. El mismo patrón con hex es imposible sin funciones de preprocesador.

La conclusión

Hex para almacenamiento y copiar-pegar. RGB para programático. HSL para ajuste del diseñador. OKLCH para rampas perceptualmente uniformes. La especificación CSS te permite mezclar libremente; elige el formato que coincida con lo que estás haciendo con el color.

Fuentes: CSS Color Module Level 4 (W3C); Björn Ottosson,A perceptual colour space (2020); documentación de funciones de color CSS modernas de MDN.

Ejemplo práctico: construir una rampa de color de UI de 10 pasos

Una rampa de sistema de diseño normalmente va de 50 / 100 / 200 / 300 / 400 / 500 / 600 / 700 / 800 / 900 — del más claro al más oscuro — con 500 como el color de marca “verdadero”. La pregunta es qué debe parecer cada paso intermedio.

Usando HSL con tono y saturación constantes, variando la luminosidad del 95% (paso 50) al 15% (paso 900):

--brand-50:  hsl(24 100% 95%);
--brand-100: hsl(24 100% 90%);
--brand-200: hsl(24 100% 80%);
--brand-300: hsl(24 100% 70%);
--brand-400: hsl(24 100% 60%);
--brand-500: hsl(24 100% 50%);  /* base */
--brand-600: hsl(24 100% 42%);
--brand-700: hsl(24 100% 34%);
--brand-800: hsl(24 100% 26%);
--brand-900: hsl(24 100% 18%);

Problema: la luminosidad de HSL es matemáticamente uniforme pero perceptualmente no. El salto de brand-400 a brand-500 parece dramático; el salto de brand-800 a brand-900 es apenas visible. La rampa se siente desigual.

OKLCH con croma constante, variando la luminosidad de 0.97 a 0.20:

--brand-50:  oklch(0.97 0.04 47);
--brand-100: oklch(0.93 0.07 47);
--brand-200: oklch(0.86 0.11 47);
--brand-300: oklch(0.78 0.15 47);
--brand-400: oklch(0.71 0.18 47);
--brand-500: oklch(0.64 0.21 47);  /* base */
--brand-600: oklch(0.55 0.20 47);
--brand-700: oklch(0.46 0.17 47);
--brand-800: oklch(0.36 0.13 47);
--brand-900: oklch(0.26 0.09 47);

Cada paso parece un paso perceptualmente uniforme del anterior. El croma se reduce al final oscuro porque los colores de alto croma simplemente no existen a baja luminosidad en sRGB — física, no una elección de herramientas. Tailwind v4, Radix Colors v3 y la mayoría de los sistemas de diseño modernos cambiaron a rampas OKLCH después de 2023 exactamente por esta razón.

Errores comunes al elegir un formato de color

• Especificar la transparencia de dos formas diferentes de manera inconsistente. rgba(255 102 0 / 0.67) y #FF6600AB son el mismo color, pero tener ambos en una hoja de estilos hace que la búsqueda y reemplazo y la creación de temas sean frágiles. Elige una notación por proyecto.
• Confiar en OKLCH a croma extremo. oklch(0.6 0.4 47) solicita un croma que la gama de visualización sRGB no puede renderizar realmente; el navegador recorta al valor renderizable más cercano. Verifica que tu intención de diseño se renderice correctamente en pantallas reales, o limita el croma al rango seguro de sRGB (máx ~0.25 para tonos cálidos, ~0.15 para amarillo-verde).
• Calcular el contraste WCAG en valores HSL o OKLCH. La fórmula de contraste WCAG 2.1 opera en sRGB de luz lineal. Las herramientas que toman entradas HSL u OKLCH convierten internamente a sRGB primero; calcular la fórmula manualmente requiere la conversión. APCA (la métrica de contraste del borrador WCAG 3) maneja la uniformidad perceptual de forma nativa y vale la pena investigarla para nuevos proyectos.
• Codificar de forma fija hex en componentes. color: #FF6600 dentro de un componente fija el color a un valor; cambiar el tema se convierte en un ejercicio de búsqueda y reemplazo. Siempre referencia propiedades personalizadas (var(--brand-500)) definidas en la raíz, no valores hex literales.
• Usar color: red u otros colores con nombre. Los colores con nombre de CSS (red = #FF0000,orange = #FFA500) son técnicamente compatibles pero tienen primarios sRGB toscos y sin diseño que raramente coinciden con una paleta de marca. Trátalos como colores de depuración, no como colores de producción.

Cuándo el formato de color CSS NO importa

• Páginas puntuales estáticas sin temas. Una página de destino con 5 colores y sin modo oscuro: elige hex, sigue adelante. Las ventajas de OKLCH solo se pagan cuando estás generando rampas o admitiendo múltiples temas.
• Salida destinada a impresión. Cualquier cosa destinada a la impresión CMYK necesita convertirse desde sRGB a través de un perfil ICC hasta el espacio de color de la prensa destino. La notación CSS es irrelevante; lo que importa es el perfil de origen y el propósito de renderizado. Consulta nuestra comparación RGB vs CMYKpara los detalles de gama y conversión.
• HTML de correo electrónico. Outlook 2007-2019 y algunos clientes de correo web todavía no admiten funciones de color CSS modernas de manera confiable. Las plantillas de correo electrónico deben recurrir a hex de 6 dígitos; OKLCH y el hex de 8 dígitos se rompen en Outlook de escritorio.
• Diseño de gama amplia P3 / Display P3 estricto. El espacio de color Apple Display P3 accesible a través de color(display-p3 ...) es una discusión completamente diferente — consulta la entrada del glosario de P3y nuestra entrada del glosario de gama para cuándo la salida de gama amplia vale la complejidad.

Para los detalles completos de la especificación, el CSS Color Module Level 4 cubre cada notación, y la publicación original de OKLab de Björn Ottosson (2020) es la referencia canónica para el modelo perceptual debajo de OKLCH. Para la conversión de formatos interactiva, el convertidor de color maneja hex ↔ rgb ↔ hsl ↔ oklch con informes de contraste WCAG.

Consideraciones de rendimiento

Las cuatro notaciones son computacionalmente equivalentes en tiempo de renderizado — el navegador convierte todo a RGB lineal internamente antes de pintar. Las diferencias de rendimiento entre notaciones están dentro del ruido de medición en cualquier dispositivo moderno. Lo que puede costar rendimiento es:

• Uso intensivo de color-mix() con argumentos de propiedad personalizada. Cada llamada a color-mix() se resuelve en tiempo de pintura; usar cientos en un solo cuadro de renderizado puede aparecer en las auditorías de Lighthouse. Precalcula las mezclas en tiempo de compilación para paletas estáticas.
• color(display-p3 ...) de gama amplia en dispositivos sin pantallas P3. El navegador realiza la asignación de gama por elemento. Gratuito en Macs con chip M y iPhones recientes; costo medible en hardware Windows más antiguo.
• Fondos semitransparentes por capas. La composición del canal alfa es rápida en GPU modernas pero lenta en Android de gama baja. Apilar 5 o más capas transparentes puede desencadenar tormentas de pintura en el 20% inferior de dispositivos.

Soporte del navegador y estrategia de respaldo

Soporte del navegador a principios de 2026:

Para correo electrónico y contextos de navegadores heredados, el objetivo seguro es el hex de 6 dígitos más soluciones separadas de canal alfa (respaldos de PNG semitransparentes). Para la web moderna, OKLCH es completamente utilizable; el raro navegador de nivel inferior probablemente también falla en características más importantes y merece una estrategia separada en lugar de compromisos de color.

La regla at @supports de CSS te permite mejorar progresivamente: define un respaldo hex primero, luego una sustitución OKLCH dentro de @supports (color: oklch(0 0 0)) para navegadores que manejan la nueva sintaxis. En la práctica pocos sitios se molestan — el grupo compatible con OKLCH es ahora más del 96% del tráfico del navegador mundial según los datos de Can I Use, y la diferencia visual entre una rampa OKLCH y un respaldo HSL es lo suficientemente pequeña como para que la estrategia más simple sea enviar un conjunto de valores y aceptar que el 3-4% vea una aproximación HSL.