Volver al blog

Publicado el 2026-08-06

De Figma a Tailwind CSS: guía práctica de conversión

Tailwind CSS es uno de los formatos de salida que más se piden al pasar un diseño de Figma a código, y también uno de los más tediosos de producir a mano. Cada valor de espaciado, color y tamaño de fuente del diseño hay que traducirlo mentalmente a la clase de utilidad Tailwind "correcta" — y ese paso de traducción es precisamente el que se come, en silencio, buena parte del tiempo de entrega.

Por qué la conversión manual de Figma a Tailwind es tan lenta

Todo el valor de Tailwind reside en una escala restringida y coherente: espaciado, color y tipografía se ajustan a un conjunto predefinido de tokens en lugar de a valores arbitrarios. Genial una vez que el código ya existe. Pero para llegar ahí desde un archivo de Figma, alguien tiene que hacer ese ajuste a mano:

  • Adivinar el paso de espaciado. Un diseñador fija un padding de 18px. ¿Es p-4 (16px) o p-5 (20px), o hace falta un valor arbitrario como p-[18px]? Multiplica esa decisión por cada gap, margin y padding del archivo.
  • Hacer coincidir los colores con el tema. El selector de color de Figma no sabe nada de la paleta de tu tailwind.config. Hay que comparar cada valor hexadecimal con los grises, azules y colores de marca del tema, o terminas con clases sueltas tipo bg-[#f4f4f5] repartidas por el código en lugar de bg-gray-100.
  • Reconstruir las escalas tipográficas. Tamaños de fuente, alturas de línea y pesos deben mapearse de forma consistente a las utilidades text-* y font-*, o títulos que en Figma se ven idénticos terminan usando tres combinaciones de clases distintas en el código.
  • Repetirlo todo en cada breakpoint. Nada de lo anterior es un coste único: se repite en cada variante responsive, a mano, sumando los prefijos sm:, md: y lg: por encima.

Ninguno de estos pasos es difícil por sí solo. Pero es exactamente el tipo de trabajo repetitivo, con poco margen de criterio, donde se cuela la inconsistencia — y unas clases de utilidad inconsistentes anulan el sentido mismo de usar Tailwind.

Cómo genera MarkupGen la salida en Tailwind a partir de un diseño real

MarkupGen está pensado para eliminar ese paso de traducción, no solo para hacerlo más rápido a mano. El flujo de trabajo es el mismo tanto si exportas a CSS plano como a Tailwind:

  1. Exporta el frame desde Figma con el plugin de MarkupGen, que captura la estructura, los estilos y las imágenes del frame y los envía a tu workspace.
  2. La IA construye el markup a partir de la estructura y el estilo reales del diseño, no de una aproximación general.
  3. Perfecciona contenido, fuentes y layout de forma visual en el editor integrado antes de dar nada por definitivo.
  4. Exporta el paquete de código final en el formato elegido.

La parte que más importa para este artículo es el paso 4: cuando se elige Tailwind CSS como formato de salida, las clases de utilidad se generan a partir de los tokens reales de espaciado, color y tipografía del diseño — no se adivinan a partir de una captura de pantalla. Un valor de padding en el frame de Figma se asigna a la utilidad de espaciado de Tailwind más cercana, un color de relleno se resuelve contra los valores de color reales del diseño, y los tamaños y pesos de fuente se trasladan a las clases text-* y font-* correspondientes. Es la misma traducción que haría un desarrollador a mano, solo que se hace directamente a partir de los datos del diseño en lugar de a ojo.

HTML/CSS plano y React son los otros dos formatos de salida disponibles — Tailwind es simplemente uno de los tres, seleccionable en cada exportación según lo que necesite el código de destino.

El Auto Layout se convierte en clases de utilidad de Flexbox

La mayoría de los archivos de Figma reales usan Auto Layout para cualquier cosa que se parezca a un componente, así que cómo se traduce importa tanto como el color o el espaciado. MarkupGen mapea la dirección, el gap, el padding y la alineación del Auto Layout a su estructura equivalente en CSS Flexbox, y en la salida Tailwind eso se traduce en las clases flex correspondientes — la dirección se convierte en la utilidad flex-row / flex-col adecuada, el gap se convierte en una utilidad gap-*, el padding se convierte en p-* / px-* / py-*, y los ajustes de alineación se convierten en utilidades items-* / justify-*. Los breakpoints responsive y el comportamiento fluido también se generan automáticamente a partir de las restricciones de redimensionado ya definidas en el frame, sin necesidad de un paso manual aparte. Para profundizar en cómo se mapea cada propiedad de Auto Layout a su equivalente en Flexbox, consulta Auto Layout to CSS.

Revisar las clases generadas antes de publicar

La conversión automática acierta con las clases de utilidad en la gran mayoría del diseño, pero sigue mereciendo la pena revisarlas antes de hacer merge:

  • Busca valores sueltos. Si un diseño usa un valor de espaciado ligeramente fuera de la escala de Tailwind, evalúa si conviene ajustar el diseño a un paso estándar o mantener el valor exacto.
  • Comprueba la consistencia de color en toda la página, sobre todo donde un componente aparece más de una vez — un mismo color visual debería resolverse siempre en la misma clase de utilidad.
  • Confirma la jerarquía de encabezados y las etiquetas semánticas, ya que el output se genera por defecto como HTML limpio y semántico, sin <div> anidados innecesarios.
  • Usa el editor integrado para ajustar contenido, fuentes o layout de forma visual en lugar de editar a mano las clases exportadas, y vuelve a exportar cuando quedes conforme.

Cada exportación recibe además una puntuación de calidad de IA automática, así tienes una señal rápida de si esa exportación está lista para publicarse o merece una segunda revisión antes de avanzar.

Pruébalo con tu propio diseño

Si todavía estás traduciendo a mano los valores de Figma a clases de Tailwind, vale la pena ver cuánto de ese trabajo desaparece cuando las clases salen de los tokens reales del diseño en lugar de una estimación. Prueba MarkupGen gratis en uno de tus frames de Figma, o lee la guía general de Figma a HTML para conocer el flujo completo de cuatro pasos. Cualquier duda, escribe a support@markupgen.com.