Figma Responsive Design: Mobile & Desktop Layouts Explained

A Figma frame that looks right on both a 1440px desktop and a 375px phone doesn't mean the responsive behavior in between is decided — Figma shows you two fixed snapshots, and a browser needs explicit rules to fill in everything a real visitor's screen size can be. Getting from "these two frames look right" to a layout that actually holds up means reading Auto Layout and constraints as responsive signal, not just visual settings, and knowing where Figma's job ends and CSS has to take over. Here's the practical mental model, what to check before you build, and where MarkupGen's automatic responsive output fits in.

A Figma frame is a visual spec, not responsive CSS

Figma renders a frame at one fixed width. Nothing in the file "plays" across screen sizes the way a browser does — what looks like responsive design in Figma is really a set of rules (Auto Layout's direction, gap and sizing modes; a layer's constraints) that describe intent, not a working simulation of a resize event. CSS is where that intent becomes real: flex-direction, gap, percentages, clamp(), and @media rules are what actually respond to viewport width. Treat the Figma file as the source of truth for intent, not as something that already contains finished responsive code.

Mobile and desktop frames describe one design, not two

It's common to see a desktop frame and a mobile frame in the same file that were designed weeks apart and quietly drifted — different heading levels, different component variants, content that exists on one and not the other for no clear reason. Treat the two frames as views of the same content model instead: the same headings, the same components (using variants for state, not one-off duplicates), and the same information in the same order unless there's a deliberate reason to reorder it. When both frames share that underlying structure, the CSS follow-through is mostly layout — stacking a row into a column, adjusting a grid's column count, collapsing secondary UI — rather than maintaining two disconnected templates.

Auto Layout and constraints: what actually carries into responsive behavior

Auto Layout's direction, gap, padding and sizing modes (hug, fill, fixed) map closely to Flexbox — see Figma Auto Layout to CSS for the full property-by-property mapping. For responsive behavior specifically, sizing mode is the signal that matters most: a "fill" element is telling you it should grow or shrink with its container (flex: 1, width: 100%), while "fixed" tells you it shouldn't.

Constraints answer a different question — how an element behaves when its parent resizes, which matters most for anything outside Auto Layout:

• Left / Right — pinned to one edge, close to a fixed offset that stays put as the parent resizes.
• Left and Right — stretches with the parent, close to width: 100% with fixed side margins.
• Center — stays centered as the parent resizes, similar to margin: 0 auto or a centered flex/grid placement.
• Scale — resizes proportionally with the parent; CSS has no single direct equivalent, and this usually gets approximated with relative units instead.
• Top / Bottom (and combinations) — the same logic applied to the vertical axis.

A lot of real files use both together: Auto Layout for how a container's children arrange themselves, constraints for how that container behaves inside something bigger than itself.

Breakpoints: going from Figma frames to real CSS

Figma has no native breakpoint feature — there's no setting that says "switch layout below 768px." What a file actually gives you is either distinct frames per screen size, or a single Auto Layout frame that resizes fluidly with no structural change at all. Which one you're looking at decides whether the CSS needs explicit @media rules, and picking breakpoint values that match where the layout genuinely changes shape — not arbitrary device widths — is most of the work. Figma Breakpoints to CSS Media Queries covers both patterns in detail and where hand-translation typically goes wrong.

Turning Figma decisions into responsive CSS

Once the Figma-side signals are clear, the CSS side is a fairly small set of tools applied consistently:

• Flexbox for most Auto Layout frames — rows, columns, nav bars, card lists.
• Grid for genuinely two-dimensional layouts, like a dashboard or gallery Auto Layout is faking with nested rows and columns.
• Media queries where the layout's shape changes — a sidebar that becomes a bottom nav, a grid that becomes a single column.
• Fluid sizing (percentages, minmax(), clamp()) for everything between the widths a designer actually specified, instead of adding breakpoints to fill the gaps.
• max-width to keep text and content from stretching uncomfortably wide on large screens, even if the Figma frame itself doesn't show one.
• Wrapping and stacking (flex-wrap, a row becoming a column) for content that should reflow rather than shrink.
• Visibility changes for anything genuinely mobile- or desktop-only — worth doing carefully, since hiding an element with display: none also removes it from the accessibility tree. See Figma to Accessible HTML if hidden content needs to stay reachable another way, like a mobile menu.

Common mistakes when translating Figma into responsive layouts

• Treating mobile as a scaled-down desktop instead of its own layout with its own hierarchy and priorities.
• Hardcoding pixel dimensions everywhere the Figma frame shows a specific number, instead of using fill/fixed sizing and constraints to decide what should actually stay fixed.
• Ignoring text wrapping — a heading or button label that fits on one line in the source language can wrap to two or three in a longer translation, and a layout that assumes single-line text breaks.
• Leaning on absolute positioning to match a design pixel-for-pixel, which looks right at the exact frame width and breaks at every width in between.
• Only checking the widths the Figma frames were drawn at — say, 375px and 1440px — and skipping everything in between, which is where most real breakage happens.

Developer handoff checklist

Before implementing responsive behavior from a Figma file, it's worth checking a few things directly in the design rather than assuming:

• Which frames exist, and whether mobile and desktop are meant to be the same content restructured, or genuinely different experiences.
• Auto Layout settings on each frame — direction, gap, padding, and sizing mode on the elements that need to resize.
• Constraints on anything outside Auto Layout, especially elements pinned to an edge or centered.
• Spacing and typography at each frame width — do they scale, or stay fixed?
• Component variants — does a component have a distinct mobile variant, or is it the same component expected to adapt?
• What's actually different between the mobile and desktop frames, and whether every difference is intentional or just drift between files edited at different times.

How MarkupGen automates the responsive baseline

Every export starts from a frame's own Auto Layout settings and resizing constraints, not a generic breakpoint list — direction, gap and padding carry over exactly, and fill/hug sizing translates into fluid CSS, so the result scales across screen sizes without hand-written media queries for most layouts.

For designs where mobile genuinely needs a different structure — a stacked nav instead of a horizontal one, a reordered hero, a hidden sidebar — the in-app editor can generate a separate, purpose-built Mobile or Desktop layout for the current page from the existing HTML/CSS, with its own media query; you review it before applying, and the visitor's screen size decides which one renders from then on. Output favors semantic HTML over nested <div>s either way, in Vanilla CSS, Tailwind, Bootstrap, Bulma, Materialize or Pico, with an automatic AI quality score on every export. None of this replaces the checklist above — it's a starting point generated from the design's real signals, worth reviewing the same way you'd review any other responsive implementation before shipping.

If you want to see how your own Figma file responds on both screen sizes, try the Figma to HTML converter — or convert straight to React if that's your stack — free, no credit card required.

FAQ

How should a Figma design handle mobile and desktop layouts? Treat them as one design expressed at two widths — the same content, headings and components — rather than two unrelated files. Auto Layout and constraints describe how that shared structure should adapt; genuine structural differences, like a collapsed nav or a reordered hero, are then implemented with CSS media queries.

Do Figma Auto Layout and constraints make a design responsive automatically? No. They describe intent — how an element should size or behave when its container changes — but that intent still has to be translated into Flexbox, Grid, fluid sizing or media queries in actual CSS. Neither Figma nor a conversion tool generates every responsive decision on its own.

How do I choose CSS breakpoints from a Figma design? Figma has no native breakpoint feature, so base breakpoints on where the layout's shape actually changes, not on arbitrary device widths. If a design uses separate frames per screen size, each frame's layout typically becomes one @media block; if it relies on Auto Layout's fluid resizing, it often needs no breakpoint at all.

What's the difference between Auto Layout and constraints in Figma? Auto Layout controls how a frame's children are arranged — direction, gap, padding, sizing — closest to display: flex. Constraints control how an element behaves when its parent resizes, like being pinned to an edge, centered, or scaled, which matters most for elements outside Auto Layout or for how an Auto Layout frame sits inside something bigger.

Should mobile and desktop be separate Figma files? Not necessarily, and keeping them in the same file with shared components usually makes drift easier to catch. What matters more than file structure is whether the two frames represent the same content model — the same components and hierarchy — with layout, not content, as the thing that changes between them.

What should I check before implementing a Figma design responsively? The frames that exist, each one's Auto Layout and constraint settings, how spacing and typography change (or don't) between them, whether components have distinct mobile variants, and which differences between the mobile and desktop frames are intentional rather than accidental drift.