MarkupGenMarkupGen
DocsRecursosBlogCasos de usoComparar
Iniciar sesiónConvierte gratis
  1. MarkupGen
  2. /Blog
  3. /Auto Layout de Figma a CSS: cómo se traduce a Flexbox (y cuándo usar Grid)
Volver al blog

Publicado el 2026-08-05 · Por El equipo de MarkupGen

Auto Layout de Figma a CSS: cómo se traduce a Flexbox (y cuándo usar Grid)

Auto Layout de Figma a CSS: cómo se traduce a Flexbox (y cuándo usar Grid)

Si alguna vez abriste un archivo de Figma y viste "Auto Layout" activado en un frame, ya estabas viendo algo muy parecido a CSS Flexbox: los diseñadores de Figma tomaron ese modelo mental a propósito. Direction, gap, padding y alignment se trasladan casi uno a uno. Donde la correspondencia Figma-a-CSS se vuelve ambigua es en el comportamiento de tamaño: "hug", "fill" y "fixed" describen una intención, no una única declaración CSS, y la salida correcta depende del contexto de layout que rodea al elemento. Entender dónde la correspondencia es directa y dónde no lo es, es lo que te permite pasar de un archivo de diseño a CSS mantenible y responsive sin adivinar cada valor a ojo.

Qué controla realmente Auto Layout

Auto Layout es la forma en que Figma hace que un frame se comporte como un contenedor de layout real, en lugar de un simple grupo de formas posicionadas de manera absoluta. Al activarlo en un frame, obtienes un conjunto de propiedades configurables:

  • Direction — si los elementos hijos se apilan vertical u horizontalmente.
  • Spacing / gap — la distancia fija entre cada elemento hijo.
  • Padding — el espacio entre el borde del frame y sus hijos, configurable por cada lado.
  • Alignment — cómo se alinean los hijos a lo largo del eje principal y del eje secundario.
  • Comportamiento de redimensionado — si el frame y sus hijos se ajustan al contenido, llenan el espacio disponible o mantienen un tamaño fijo.

Nada de esto es arbitrario. Cada propiedad existe porque corresponde a algo que un motor de layout real necesita saber, y por eso se traduce de forma tan limpia a CSS Flexbox en la mayoría de los casos.

Figma Auto Layout a Flexbox: tabla de correspondencia

Esta tabla es el núcleo práctico de la traducción de Figma a CSS. La mayoría de las filas son un cambio directo; algunas dependen del contexto, algo que la columna de Notas señala explícitamente.

Propiedad Auto Layout de Figma Equivalente en CSS Notas
Dirección horizontal flex-direction: row Valor por defecto de Flexbox; los hijos se colocan de izquierda a derecha.
Dirección vertical flex-direction: column Los hijos se apilan de arriba abajo.
Gap gap Equivalente directo — no hace falta recurrir a trucos con margin.
Padding padding Se aplica al frame que tiene Auto Layout activado, no a sus hijos.
Alineación (eje principal) justify-content El control de alineación del "eje principal" de Figma.
Alineación (eje secundario) align-items, o align-self en un hijo concreto Figma permite que un solo hijo sobrescriba la alineación del grupo — eso se traduce en align-self, no en un segundo align-items.
Hug contents a menudo sin tamaño explícito, o width/height: fit-content No es una regla universal — depende de si el elemento es un flex item, un elemento de bloque, u otra cosa.
Fill container flex: 1, width: 100%, o align-self: stretch, según el eje Ninguna declaración CSS única llena siempre un contenedor; la correcta depende del modo de layout del padre.
Ancho/alto fijo width / height explícitos, a veces con límites min-/max- Directo, pero conviene comprobar si el diseño implica un límite estricto o solo un tamaño por defecto habitual.
Modo de espaciado ("packed" vs. "space between") gap para packed; justify-content: space-between para space-between En Figma suelen ser mutuamente excluyentes — space-between distribuye el espacio en vez de usar un gap fijo.
Auto Layout anidado elementos anidados, cada uno con su propio display: flex Cada frame anidado es su propio contexto de formato flex — traduce la estructura, no solo los valores.

La salvedad importante: "Fill container" en Figma no siempre se traduce en una única declaración CSS universal. Que deba convertirse en flex: 1, width: 100% o align-self: stretch depende de si el elemento está dentro de un contenedor flex, un contenedor de bloque o una grid — la misma propiedad de Figma puede requerir CSS distinto según su padre.

El modelo mental: contenedor Auto Layout → contenedor flex

Una vez que se elimina la interfaz de Figma, los conceptos se alinean directamente:

Figma CSS
Frame con Auto Layout Contenedor con display: flex
Direction flex-direction
Alignment align-items / justify-content
Gap gap
Padding padding
Comportamiento de tamaño (hug / fill / fixed) propiedades width / height / flex

Todo frame con Auto Layout es un contenedor flex en potencia. El trabajo consiste en decidir, para cada frame, qué significa realmente su comportamiento de tamaño en el CSS correspondiente — lo que se explica a continuación.

Hug contents, fill container y tamaño fijo

El comportamiento de tamaño es donde más falla la traducción manual de Figma a CSS, porque Figma expresa una intención mientras que CSS exige una declaración concreta.

Hug contents

Un elemento "hug contents" se dimensiona en torno a su contenido: no tiene una dimensión fija y crece o se reduce según cambia el contenido. En la web, el equivalente más cercano suele ser simplemente no fijar un width o height explícito, ya que los elementos de bloque y los flex items ya se dimensionan según su contenido por defecto. Cuando sí hace falta ser explícito, width: fit-content o height: fit-content se acerca bastante, pero no es universalmente equivalente: dentro de un contenedor flex, un item sin flex-grow ya se comporta como "hug" sin CSS adicional, así que añadir fit-content encima puede ser redundante o, en algunos navegadores, sutilmente distinto del comportamiento por defecto.

/* Figma: Hug contents, Auto Layout horizontal */
.button {
  display: flex;
  width: fit-content; /* a menudo innecesario — los flex items ya se ajustan al contenido por defecto */
}

Fill container

Un elemento "fill container" se expande para ocupar el espacio disponible. El CSS correcto depende por completo del padre:

  • Dentro de un contenedor flex, en el eje principal: flex: 1 (o flex-grow: 1).
  • Dentro de un contenedor flex, en el eje secundario: align-self: stretch.
  • Dentro de un padre de tipo bloque: width: 100%.
/* Figma: Fill container, hijo de un frame Auto Layout horizontal */
.sidebar-content {
  flex: 1;
}

No existe una única regla "fill container → CSS" que funcione en todas partes. Si el contexto de layout del padre está equivocado, flex: 1 en un elemento que no es un flex item no hace nada.

Fixed (tamaño fijo)

Las dimensiones fijas en Figma suelen traducirse en un width y/o height explícito en CSS. Pero un valor en píxeles copiado literalmente de Figma no siempre es el objetivo correcto: conviene comprobar si el diseño implica una restricción estricta (width: 240px) o un límite sobre un elemento por lo demás flexible (min-width / max-width, min-height / max-height). Tratar cada valor fijo como un width estricto es una causa habitual de layouts que no se adaptan a contenido real o a distintos viewports.

Auto Layout vs. Constraints

Auto Layout y Constraints resuelven problemas relacionados pero distintos, y confundirlos es una fuente frecuente de errores de traducción.

  • Auto Layout controla cómo se organizan los hijos de un frame entre sí: dirección, gap, padding, alineación y comportamiento de tamaño. Es el equivalente más cercano a display: flex.
  • Constraints controlan cómo se comporta un elemento cuando su padre cambia de tamaño: anclado a izquierda/derecha/arriba/abajo/centro, o escalado. Las constraints son más relevantes para elementos que no están dentro de un frame Auto Layout, o para cómo se comporta el propio frame Auto Layout dentro de un padre de tamaño fijo.

En la práctica, el CSS final de un elemento suele necesitar información de ambos: Auto Layout indica las propiedades flex de un contenedor y sus hijos, mientras que las constraints indican si ese contenedor debe tratarse como fijo o debe redimensionarse junto con su propio padre. Ninguno de los dos por sí solo da el panorama responsive completo.

Cómo Auto Layout ayuda con el CSS responsive

Auto Layout aporta señales reales para el comportamiento responsive, pero no se convierte automáticamente en CSS responsive por sí solo. Vale la pena ser precisos sobre lo que realmente ofrece:

  • El comportamiento de tamaño de Auto Layout (hug / fill / fixed) indica qué elementos deben crecer, encogerse o mantenerse fijos — esa es la base de un layout responsive, traducida directamente en flex, width: 100% o un tamaño fijo.
  • Las constraints de Figma añaden información sobre cómo deben comportarse los elementos cuando su contenedor cambia de tamaño, algo relevante para todo lo que no gobierna Auto Layout.
  • Ninguno de los dos genera breakpoints. Si el layout de un diseño realmente cambia de forma en ciertos anchos —columnas que se apilan, navegación que se colapsa—, eso sigue requiriendo media queries CSS, porque los frames de Figma suelen representar unos pocos tamaños de viewport fijos, no todo el rango entre ellos.
  • Entre los tamaños que el diseñador especificó realmente, un tamaño fluido (porcentajes, flex, minmax(), clamp()) suele reproducir el comportamiento previsto con más fidelidad que añadir breakpoints extra para rellenar los huecos.

El objetivo es reproducir el comportamiento previsto del layout en distintos viewports, no copiar las dimensiones en píxeles del frame de Figma que se tenía delante en ese momento.

Cuándo CSS Grid es mejor opción

Auto Layout es un modelo de un solo eje: funciona muy bien con filas y columnas, incluyendo combinaciones anidadas de ambas. Pero algunos diseños son genuinamente bidimensionales, y forzarlos en Flexbox anidado produce código más difícil de mantener que el propio diseño. La elección correcta depende del layout: Flexbox encaja en disposiciones unidimensionales (navegación, grupos de botones, una fila de tarjetas, contenido alineado vertical u horizontalmente), mientras que Grid encaja en las bidimensionales. Recurre a CSS Grid cuando veas:

  • Un layout donde los elementos necesitan alinearse tanto en filas como en columnas al mismo tiempo — piensa en grids de tarjetas, dashboards o galerías de imágenes.
  • Comportamiento explícito del tipo "este elemento ocupa dos columnas" o "dos filas", que Grid maneja de forma nativa con grid-column / grid-row y que Flexbox no puede expresar directamente.
  • Diseños donde el número de columnas debe responder al ancho disponible (repeat(auto-fit, minmax(...))) en lugar de a una lista fija de breakpoints.
  • Regiones superpuestas o en capas dentro de una misma grilla, algo sencillo con el sistema de posicionamiento de Grid pero incómodo con Flexbox.

Una buena regla general: si el Auto Layout de un frame de Figma solo se anida en una dirección a la vez, Flexbox es una traducción fiel. Si te encuentras construyendo una grilla de frames Auto Layout solo para simular la alineación de filas y columnas, suele ser señal de que la interfaz de Figma está compensando la falta de un modo de layout Grid bidimensional nativo, y en ese caso conviene generar CSS Grid de verdad.

Errores frecuentes al pasar de Auto Layout a CSS

Incluso con una correspondencia clara, los desarrolladores que reproducen Auto Layout a mano suelen tropezar con los mismos detalles:

  • La alineación mixta se aplana. Figma permite que hijos individuales sobrescriban la alineación del grupo; es fácil pasar esto por alto y aplicar un único valor de align-items a todo, perdiendo los overrides individuales que necesitarían align-self.
  • Ambigüedad entre "hug" y "fill". Un frame configurado para ajustarse a su contenido se ve idéntico a un frame de ancho fijo en un solo tamaño de viewport, pero se comporta de forma completamente distinta cuando cambia el contenido o el tamaño de pantalla.
  • Se omite gap a favor de margin. Algunos desarrolladores siguen recurriendo a trucos con margin en lugar de gap, heredados de consejos antiguos de Flexbox; ya no es necesario ahora que gap cuenta con buen soporte en los navegadores, y hacerlo reintroduce exactamente los bugs de espaciado que gap estaba pensado para resolver.
  • Los frames Auto Layout anidados se convierten en contenedores flex anidados sin ningún plan. Cada frame anidado es su propio contexto flex, y una traducción literal uno a uno puede producir más elementos wrapper de los que el layout realmente necesita.
  • El padding se aplica al elemento equivocado. Es fácil aplicar el padding de un frame a un hijo en lugar de al contenedor, lo que descuadra el espaciado basado en gap entre elementos hermanos.
  • Asumir que Auto Layout por sí solo hace responsive un layout. Como se explicó antes, Auto Layout y las constraints informan el comportamiento responsive, pero no sustituyen a las media queries cuando la forma del layout realmente necesita cambiar.
  • Anidar Flexbox para simular una grilla bidimensional. Si estás apilando frames Auto Layout para alinear filas y columnas a la vez, normalmente es señal de que CSS Grid es el objetivo más adecuado.

Auto Layout en un flujo de trabajo de Figma a código

Esta correspondencia se entiende bien, pero aplicarla correctamente en cada frame, cada valor de gap y cada contenedor anidado de un archivo de diseño real —interpretando además dirección, tamaño y jerarquía entre frames— es un trabajo tedioso. Es exactamente el tipo de trabajo de traducción repetitivo que MarkupGen está diseñado para ayudar a resolver. El flujo de trabajo tiene cuatro pasos: exportas el frame desde Figma con el plugin complementario, que lleva la estructura, los estilos y las imágenes a tu workspace; la IA de MarkupGen construye HTML y CSS a partir de esa estructura, mapeando la dirección, el gap, el padding y la alineación de Auto Layout a una estructura Flexbox equivalente; luego refinas el contenido, las fuentes y el layout de forma visual en un editor integrado; y por último exportas el paquete final. Los breakpoints responsive se generan a partir de las restricciones de redimensionado del diseño, y eliges el formato de salida — HTML/CSS puro, Tailwind CSS, o componentes React — según tu stack. Como con cualquier conversión automatizada, conviene revisar el comportamiento de tamaño en elementos hug/fill/fixed y los breakpoints que infiere: son un buen punto de partida, no un sustituto de comprobar el resultado contra el diseño. Si prefieres partir de un ejemplo funcionando en vez de un archivo en blanco, prueba el conversor de Figma a HTML de MarkupGen con tu propio diseño, o lee la guía completa de conversión de Figma a HTML para ver el flujo de trabajo de principio a fin.

Preguntas frecuentes

¿Cómo se traduce Figma Auto Layout a CSS? Direction, gap, padding y alignment se traducen directamente en flex-direction, gap, padding y justify-content/align-items. El comportamiento de tamaño —hug, fill y fixed— también se traduce a CSS, pero la declaración exacta depende del contexto de layout, no es un cambio uno a uno fijo.

¿Es Figma Auto Layout lo mismo que CSS Flexbox? Están estrechamente relacionados, pero no son idénticos. Auto Layout se modeló deliberadamente sobre los conceptos de Flexbox, así que la mayoría de las propiedades se trasladan directamente. La diferencia principal es que Figma expresa el tamaño como intención de diseño (hug, fill, fixed), mientras que CSS exige elegir la declaración concreta que produce esa intención en un contexto determinado.

¿Qué significa "hug contents" en CSS? Significa que el elemento se dimensiona en torno a su contenido, en lugar de tener un tamaño fijo o estirado. En la web suele ser el comportamiento por defecto de los elementos de bloque y los flex items sin un ancho explícito, o puede hacerse explícito con width: fit-content / height: fit-content cuando hace falta.

¿Qué significa "fill container" en CSS? Significa que el elemento se expande para usar el espacio disponible en su padre. Según el contexto, eso equivale a flex: 1 en el eje principal de un contenedor flex, align-self: stretch en el eje secundario, o width: 100% dentro de un padre de tipo bloque — no hay una única declaración que aplique siempre.

¿Figma Auto Layout genera CSS responsive automáticamente? No. El comportamiento de tamaño de Auto Layout y las constraints de Figma aportan información útil sobre cómo deben adaptarse los elementos, pero los breakpoints para layouts que cambian de forma en distintos anchos aún hay que escribirlos como media queries CSS.

¿Debería usar CSS Grid o Flexbox para un diseño de Figma? Depende del layout, no de cuál es "mejor". Flexbox encaja en disposiciones unidimensionales — filas, columnas, navegación, grupos de botones. Grid encaja en layouts genuinamente bidimensionales, como dashboards o grids de tarjetas donde los elementos deben alinearse en filas y columnas a la vez.

Pruébalo con Figma to HTML

Lecturas relacionadas

Figma to HTML vs React vs Tailwind: ¿cuál elegir?Blog

Figma to HTML vs React vs Tailwind: ¿cuál elegir?

Una guía de decisión para las tres opciones de salida más consultadas de MarkupGen: cuándo exportar Figma a HTML/CSS, cuándo exportarlo a React, y dónde encaja realmente Tailwind.

Leer más
De Figma a código: soporte de React, Vue y frameworks CSS en MarkupGenBlog

De Figma a código: soporte de React, Vue y frameworks CSS en MarkupGen

MarkupGen convierte un diseño de Figma en componentes React o Vue 3 (además de Svelte y Angular), o en HTML/CSS con Tailwind, Bootstrap y más.

Leer más
Cómo evaluar HTML generado por IA antes de publicarloBlog

Cómo evaluar HTML generado por IA antes de publicarlo

Una checklist repetible para juzgar la salida de Figma a código con IA más allá de 'se ve bien' — fidelidad visual, semántica, responsividad, accesibilidad y peso.

Leer más
¿La salida de Figma a HTML está lista para SEO? Qué comprobarBlog

¿La salida de Figma a HTML está lista para SEO? Qué comprobar

El HTML convertido puede verse idéntico al diseño y aun así perjudicar el SEO. Una checklist de qué verificar antes de publicar una exportación de Figma a código.

Leer más
De Figma a HTML accesible: guía prácticaBlog

De Figma a HTML accesible: guía práctica

Lo que la accesibilidad realmente exige en un flujo de trabajo de Figma a HTML: marcado semántico, encabezados, ARIA, formularios, contraste y navegación por teclado.

Leer más
De Figma a CSS: guía práctica de conversiónBlog

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

Olvídate por completo de la dependencia de un framework. Cómo se convierten los valores de Figma en CSS plano y editable a mano — y cuándo es la mejor opción frente a Tailwind o Bootstrap.

Leer más
Comparar

MarkupGen vs. TeleportHQ: conversor vs. plataforma low-code

TeleportHQ combina la exportación de Figma a código con un CMS, formularios y hosting integrados; MarkupGen se mantiene enfocado en un resultado HTML/CSS/React limpio e independiente.

Leer más
MarkupGen para desarrolladores front-endCasos de uso

MarkupGen para desarrolladores front-end

Olvídate de reconstruir a mano. Convierte frames de Figma en HTML/CSS o React limpio y dedica tu tiempo a la lógica, no al layout.

Leer más

Convierte tu próximo diseño de Figma en código en minutos

Empieza gratis y exporta HTML, CSS o React limpio desde cualquier archivo de Figma.

Convierte gratis
MarkupGenMarkupGen© 2025 MarkupGen. Todos los derechos reservados.
BlogCasos de usoCompararRecursos
Acerca deDocumentaciónPrivacidadTérminosContacto