Why Figma Auto Layout breaks after importing a web page

A row of cards that sat flush in the browser arrives in Figma with one card four pixels low. Nothing is broken enough to point at. Here is what actually happened.

You import a web page into Figma, the layers panel fills up, and something is off. A row of cards that sat flush in the browser now has one card nudged four pixels low. A nav bar that was centred is centred-ish. Nothing is broken enough to point at, but the file no longer matches the screenshot you took next to it.

This is almost always Auto Layout, applied where it should not have been. It is worth understanding why it happens, because the fix is not "turn Auto Layout off" — it is knowing when the two layout systems genuinely agree and when a tool is guessing.

Two layout engines that were never meant to agree

A browser lays out a page with CSS. Flexbox, grid, floats, inline flow, margin collapsing, line-height that pushes text off its own box, sub-pixel rounding that differs per platform. Decades of rules, most of them edge cases that only matter once.

Figma lays out a frame with Auto Layout. It is a much smaller system, and deliberately so: a direction, a gap, four padding values, alignment on two axes, and per-child grow and stretch. That is nearly all of it.

Auto Layout is not a re-implementation of flexbox. It resembles flexbox the way a bicycle resembles a motorcycle. So when a converter reads display: flex and sets layoutMode: "HORIZONTAL", it is making a claim: these two systems will put every child in the same place. Sometimes that claim is true. Often it is nearly true, which is worse.

Where the two quietly disagree

Some concrete cases, all of which look like flexbox and none of which Auto Layout reproduces:

• Margins on flex items. CSS lets a child carry its own margin, including margin-left: auto to push a group right. Auto Layout has one gap for the whole frame and no per-child margin at all.
• space-around and space-evenly. Auto Layout has SPACE_BETWEEN. The other two distribute leftover space differently, and there is no setting that reproduces them.
• align-items: baseline. Text of different sizes sitting on a shared baseline is common in headings and price rows. Auto Layout aligns on box edges and centres, not baselines.
• Fractional flex-grow. flex: 1 maps onto layoutGrow: 1. flex: 2 and flex: 0.5 map onto nothing.
• flex-wrap. A wrapped row is a different geometry from a single row, and the wrap point depends on the container width at capture time.
• Text remeasurement. This is the one that catches tools out. A text layer set to hug its content is measured by Figma, using the font Figma has, at the size Figma computed. If that measurement differs from the browser's by even a pixel, every sibling after it in the stack moves.

That last one is why the problem often appears only after you have installed a missing font, or only on someone else's machine.

Why converters apply it anyway

Because a file full of Auto Layout frames looks like a better product than a file full of absolutely positioned rectangles. It demos well. It is a bullet point. And in the common case — a simple row, a card grid with equal gaps — it genuinely is better, because you can then resize the frame and have it behave.

The failure mode is that the tool cannot tell the common case from the near miss without checking, and checking is more work than not checking.

What to do about it

If you have already imported

Pick the frame that looks wrong and set its layout mode to none. In Figma this is the layout section of the right-hand panel. The children keep their current positions, so if the shift already happened, this freezes it rather than undoing it — which is why the useful move is usually to re-import rather than repair.

Before you do, check one thing: are the fonts the page used actually installed on your machine? A substituted font remeasures every text layer, and no amount of layout fiddling fixes a file whose text is the wrong width. Figma tells you which fonts are missing when you open the file.

If you are choosing a tool

Ask what it does when the two systems disagree. There are three possible answers, and only one of them is good:

1. Apply Auto Layout everywhere it sees flexbox. Fast, demos well, and hands you a file that has quietly moved.
2. Never apply it. Always correct, never useful. You get a pile of absolutely positioned layers that are exact and painful to edit.
3. Apply it only where it reproduces the original. Correct and useful, but it requires the tool to actually predict what Figma will do and compare.

How Snapture decides

Snapture takes the third option, and the mechanism is simple enough to describe in a paragraph.

At capture time it already knows where every element sits, because it read the rendered page: it has the real, browser-computed rectangle for each child. Before attaching a layout, it simulates what Figma's engine would do with the same frame — the padding, the gap, the alignment, the grow distribution — and produces a predicted rectangle for each child. Then it compares the two sets. If every child lands within half a pixel of where the browser put it, the layout is attached. If any child misses, the whole frame keeps exact absolute coordinates instead.

There is a second check on the other side. After the Figma plugin applies the layout, it measures the children again — this time against the real engine rather than a prediction — and if anything moved beyond that same half pixel, it reverts the frame to the captured coordinates. That check exists because a text layer can remeasure at import time in a way no simulation can foresee.

What that looks like in practice

Running the converter against real pages gives a sense of how selective it is. These are counts from the same measurement run published on the proof page:

The MDN row is the interesting one. Five Auto Layout frames out of 253 nodes looks like the tool failing. It is the tool working: MDN's article layout is largely document flow and floats, which Auto Layout does not model at all, so the gate rejected nearly everything and kept exact positions. The import is pixel-accurate and mostly not auto-laid-out, which for that page is the correct trade.

Linear, by contrast, is built almost entirely out of flex rows with uniform gaps. 261 of its frames genuinely survive the comparison, and those frames behave properly when you resize them in Figma.

The short version

Auto Layout after an import is only trustworthy if something verified it. Flexbox and Auto Layout overlap enough to fool a converter and differ enough to shift your file, and the difference usually shows up as a few pixels rather than as an obvious break — which is exactly the kind of error that costs the most time to find.

If a tool cannot tell you what it does when the two disagree, assume it does not check.

English · 한국어 · 日本語 · 简体中文 · 繁體中文 · Español · Português · Français · Deutsch · Русский · Italiano · Bahasa Indonesia