Design tokens vs variables CSS vs Tailwind: qué resuelve cada uno

Un design token es el registro independiente de plataforma de una decisión de diseño (un color, un paso de espaciado, un radio) almacenado en un formato estructurado que puede compilarse a CSS, Swift, Kotlin, XML o a un tema de Tailwind. Las variables CSS son la primitiva nativa del navegador que sostiene esos valores en tiempo de ejecución. Tailwind es un framework de utilidades que, desde la versión 4, genera clases a partir de las variables CSS que declaras en un bloque de tema. Los tres viven en tres capas distintas del mismo stack y la comparación solo tiene sentido cuando dejas de tratarlos como alternativas.

Este artículo es para equipos de producto a punto de escoger una arquitectura de estilos para un nuevo SaaS o que están considerando una migración. Mapeamos los tres conceptos a la capa que realmente ocupan, listamos dónde cada uno es la herramienta correcta, nombramos los modos de fallo que vienen de confundirlos y cerramos con la elección que hacemos en Studio y por qué.

TL;DR para impacientes

Elige design tokens (en formato W3C DTCG) cuando más de una plataforma debe consumir las mismas decisiones de diseño, cuando el equipo de diseño trabaja en Figma con Tokens Studio o cuando quieres una fuente única de verdad que sobreviva a un cambio de framework. Usa variables CSS como implementación en tiempo de ejecución de esos tokens para la web. Recurre a Tailwind cuando el equipo valora la velocidad y un vocabulario de utilidades compartido en una superficie pequeña o mediana, y acepta que la v4 lo convirtió en una capa fina sobre tus variables CSS en lugar de un sistema paralelo. Sáltate Tailwind cuando el proyecto lleva un design system maduro, corre en muchas apps consumidoras o mide cada kilobyte de CSS enviado.

Las tres capas, en simple

Los design tokens son un formato, no una feature

El W3C Design Tokens Community Group (DTCG) publicó la primera versión estable del Design Tokens Format Module el 28 de octubre de 2025. El formato es JSON, las propiedades llevan el prefijo $ y los archivos usan la extensión .tokens o .tokens.json con media type application/design-tokens+json. Un archivo de tokens es un documento vendor-neutral que cualquier herramienta compatible (Figma, Penpot, Sketch, Framer, Knapsack, Supernova, zeroheight, Tokens Studio, Style Dictionary, Terrazzo) puede leer o escribir.

{
  "color": {
    "brand": {
      "primary": { "$type": "color", "$value": "#3D5AFE" }
    }
  },
  "radius": {
    "md": { "$type": "dimension", "$value": "8px" }
  }
}

Ese archivo por sí solo no hace nada. Una herramienta de build (Style Dictionary es la implementación de referencia, Terrazzo es el desafiante moderno) lo compila a lo que el target necesite: custom properties CSS para web, una extension Swift para iOS, un object Kotlin para Android, un módulo JS para React Native, un theme de Tailwind. El token está aguas arriba de cada implementación.

Las variables CSS son el runtime de la web

Las custom properties CSS (nombre de la especificación; todos dicen variables CSS) están sujetas a la cascada, pueden sobrescribirse en cualquier selector y leerse desde cualquier propiedad que acepte ese tipo de valor. Son el único mecanismo en el navegador que permite que una única declaración sea tematizada, intercambiada en tiempo de ejecución o leída desde JavaScript sin recompilar.

:root {
  --color-brand-primary: #3D5AFE;
  --radius-md: 8px;
}

[data-theme="dark"] {
  --color-brand-primary: #8C9EFF;
}

.button {
  background: var(--color-brand-primary);
  border-radius: var(--radius-md);
}

Si alguna vez has lanzado un dark mode funcional sin un build step, has usado variables CSS. No son un design system, son el cable entre tus tokens y los píxeles.

Tailwind es un framework que consume variables CSS

Tailwind CSS v4, lanzado a principios de 2025, reescribió el motor en Rust (Oxide), eliminó el archivo de configuración JavaScript y movió el design system a un bloque CSS-native @theme. Los valores que declaras en @theme se convierten tanto en variables CSS como en la fuente de las clases utility generadas.

@import "tailwindcss";

@theme {
  --color-brand-primary: #3D5AFE;
  --radius-md: 8px;
}

/* genera: bg-brand-primary, text-brand-primary, rounded-md, etc. */

El cambio importa. En v3, los design tokens vivían en tailwind.config.js y quedaban atrapados en el build step. En v4 viven como variables CSS reales que DevTools puede leer y otro CSS puede referenciar. Tailwind se convirtió en un generador de utilidades sobre variables que tú controlas, en lugar de un ecosistema paralelo.

Tabla comparativa

DimensiónDesign tokens (DTCG)Variables CSSTailwind v4CapaFuente de verdadRuntime del navegadorGenerador de utilidadesDónde vivenArchivos JSON (.tokens.json)Dentro del CSS, scoped a selectoresBloque @theme en CSSMultiplataformaSí (web, iOS, Android, RN)Solo webSolo webTheming en runtimeA través de variables CSS compiladasNativo, sin rebuildNativo via variables subyacentesApto para diseñadoresSí (los plugins de Figma leen DTCG)No, territorio devParcial, requiere fluidez con utilidadesBuild stepRequerido (Style Dictionary, Terrazzo)NingunoRequerido (compilador Tailwind)Riesgo de lock-inBajo, spec vendor-neutralNinguno, estándar webMedio, sintaxis específica del frameworkTamaño de salidaLo que compilesBytes que escribesSolo las utilidades que de verdad usas

Dónde ganan los design tokens

Los tokens se ganan su lugar en el momento en que aparece una segunda plataforma. Una app iOS nativa que tiene que compartir colores de marca con la web no puede consumir CSS, pero sí puede consumir un build de Style Dictionary que emite un archivo Swift desde el mismo JSON que consume la web. Un equipo de diseño trabajando en Figma con Tokens Studio escribe DTCG de forma nativa; sin esa capa, cada actualización de marca se vuelve un port manual. Los SaaS multi-brand o multi-tenant ganan lo mismo: cada tenant entrega un set de tokens, Style Dictionary compila bundles de variables CSS por tenant, el runtime queda idéntico.

Los tokens también actúan como contrato entre diseño e ingeniería que no depende de las modas de tooling. Que el formato DTCG haya alcanzado el estado estable a finales de 2025 significa que un archivo de tokens escrito hoy debería seguir siendo parseable dentro de cinco años, sin importar qué framework lleve el frontend.

Dónde ganan las variables CSS

Las variables CSS ganan el runtime. Son la única forma sana de enviar dark mode, modos de densidad, themes de marca o skins por tenant sin rebuild. Son cero dependencias, cero build y soportadas en todos los navegadores que importan. Leer una variable desde JavaScript con getComputedStyle funciona sin archivo de config. Sobrescribir una variable en una media query intercambia tokens sin tocar el markup.

Para un sitio pequeño de marketing o un producto de marca única sin integraciones con herramientas de diseño, las variables CSS por sí solas suelen bastar: escríbelas en un bloque :root, documéntalas en un README, envía. El formato DTCG se vuelve overhead si no existe un segundo consumidor.

Dónde gana Tailwind

Tailwind se gana su lugar cuando la velocidad del equipo y un vocabulario compartido importan más que la arquitectura del CSS. Un equipo pequeño prototipando un producto nuevo puede moverse más rápido con clases utility que con un design system custom, porque el coste de nombrar componentes es cero. La v4 añadió el puente @theme, así que los tokens que declaras son accesibles también para CSS no-Tailwind, lo que quita lo peor del lock-in de v3.

Tailwind también entrega un set de tokens por defecto respetable (escala de espaciado, rampa de colores en OKLCH, escala tipográfica) sobre el que un equipo junior puede apoyarse mientras aprende. Para sitios escaparate, herramientas internas y productos sin un design system formal, Tailwind es un default defendible.

Los tres modos de fallo de confundirlos

Tratar Tailwind como un design system

Tailwind genera utilidades. No impone naming semántico, no documenta contratos de componente ni audita el uso indebido de tokens en varios proyectos consumidores. Un equipo que llama design system a Tailwind tiende a enviar valores hardcoded dentro de clases utility (bg-[#3D5AFE], p-[17px]) en pocos meses. El arreglo es prohibir los valores arbitrarios en el lint, declarar cada valor en @theme y tratar el bloque theme como el registro de tokens.

Saltarse la capa de tokens porque existen las variables CSS

Un equipo que va directo de Figma a las variables CSS pierde el único artefacto que sobrevive a una migración de framework. El archivo CSS es la implementación, no la fuente. Cuando aparece la segunda plataforma (app móvil, sync con la herramienta de diseño, marca partner), el equipo vuelve a portar a mano. El arreglo es escribir primero el JSON de tokens aunque el único consumidor hoy sea la web; Style Dictionary se configura en pocas horas.

Tratar los tokens como una copia JSON del CSS

Tokens que reflejan el CSS uno a uno (color-blue-500 en JSON, --color-blue-500 en CSS) pierden el punto. Los tokens cargan significado semántico (color.action.primary, color.surface.elevated) que mapea a muchos valores concretos a través de themes y plataformas. Una paleta de colores plana en JSON es una paleta de colores, no un sistema de tokens.

Qué usamos en Studio y por qué

Studio mantiene un design system interno que se entrega como paquete NPM y alimenta más de una docena de proyectos consumidores. Definimos los tokens en JSON, los compilamos a variables CSS (el namespace --ds-*) con un build de Style Dictionary y los consumimos en CSS Modules y CSS de componentes. Quitamos Tailwind de producción hace tres años después de que cruzara el 50% del peso del bundle en un proyecto que necesitaba LCP por debajo de 1s en todas partes.

El razonamiento no era estético. Era que el design system ya imponía el naming, documentaba cada contrato de componente y podía hacer lint del mal uso de tokens en todos los proyectos consumidores desde un manifest central. Tailwind se convertía en un sistema de naming paralelo que diluía el contrato. Para nuevo trabajo cliente donde no hay un design system interno sobre el que apoyarse y el proyecto se entrega en semanas, todavía recomendamos Tailwind v4 con un bloque @theme estricto y el lint de valores arbitrarios desactivado.

El árbol de decisión que aplicamos: más de una plataforma, o herramientas de diseño que hablan DTCG de forma nativa, o theming en runtime entre tenants, entonces la capa de tokens JSON no es negociable. Solo web, marca única, madurez de design system por encima de tres años, entonces las variables CSS compiladas desde tokens bastan. Solo web, sin design system, equipo de menos de cinco personas entregando en semanas, entonces Tailwind v4 con disciplina de tokens es el camino defendible más rápido.