Convertidor de color para Tailwind CSS: OKLCH, @theme y escalas de tono

Desde la v4 la paleta por defecto de Tailwind se define en OKLCH en lugar de hex o RGB. El motivo es la uniformidad perceptual. Un azul en lightness 0.5 se ve igual de claro que un rojo en lightness 0.5, cosa que no pasa en HSL ni en sRGB. La escala de tonos (50, 100, 200 ... 950) tiene saltos de contraste consistentes en cualquier hue.

Efecto práctico: los colores se ven más parejos al intercambiarlos, las variantes de dark mode necesitan menos retoque manual, y el checker de contraste deja de quejarse a saltos aleatorios en la escala. Coste: los valores OKLCH no se parecen a nada legible a ojo, no puedes adivinar un color mirando oklch(0.65 0.18 250) como sí puedes con #3a86ff.

Mapear un hex de marca a Tailwind v4 significa pasarlo a OKLCH, elegir el tono más cercano de la escala existente, y o usar ese tono tal cual o generar una rampa custom 50..950 en torno a él.

El enfoque ingenuo es elegir cinco niveles de lightness (90, 75, 60, 45, 30) al mismo chroma y hue y llamarles 100, 300, 500, 700, 900. Vale como primera pasada y se rompe en los extremos, el chroma tiene que bajar cerca del blanco puro y del negro puro o el color sale neón en el extremo claro y barroso en el oscuro.

Receta mejor: parte del hex de marca, pásalo a OKLCH, coge el chroma como pico. Construye la rampa fijando el hue, bajando el chroma hacia los extremos (algo tipo chroma * sin(pi * lightness) si quieres una curva), y subiendo la lightness desde 0.97 (50) hasta 0.20 (950). La paleta propia de Tailwind usa una curva parecida.

Para la mayoría de proyectos no hace falta hacerlo a mano. Las herramientas (el conversor de este sitio, más generadores de rampas pensados para Tailwind) cogen un hex y escupen los once stops OKLCH. Los pegas en tu bloque @theme y tienes una paleta custom que cuadra con el resto del framework.

En la v4 el sitio canónico para los design tokens es @theme dentro de tu CSS. La sintaxis declara custom properties CSS bajo namespaces específicos de Tailwind, y el framework las recoge automáticamente.

Para un color el namespace es --color--. Defines once y tienes una paleta con el nombre que elegiste, con las utilidades estándar 50..950 (bg-brand-500, text-brand-900, etc.) generadas solas.

La config legacy en JS sigue funcionando para migración pero va camino de deprecación. Los proyectos nuevos en v4 entregan un único archivo CSS con @import "tailwindcss"; y un bloque @theme debajo, y el archivo JS desaparece entero. El bloque de abajo es una rampa de marca completa lista para pegar en app.css o globals.css.

Con la rampa puesta, dos convenciones más cierran el sistema. La primera son los aliases semánticos: --color-primary apunta a var(--color-brand-500) (o 600 si quieres un default más oscuro), --color-primary-hover apunta a 600 o 700, y tu código de componentes usa bg-primary en vez de bg-brand-500. Cambiar nombre o marca es entonces una sola línea.

La segunda es dark mode. El enfoque ingenuo es invertir cada tono con su espejo (50 toma el valor de 950, 950 el de 50). Funciona pero produce colores apagados en el extremo claro. El patrón limpio es dejar la rampa intacta y voltear solo los aliases semánticos: --color-primary apunta al 500 en light y al 400 en dark, porque OKLCH 400 sobre fondo oscuro tiene el mismo contraste percibido que 500 sobre fondo claro. El resultado es peso visual consistente en ambos modos sin doblar el número de tokens.