Bringing Adobe XD's Stack and Repeat Grid into Figma's Auto Layout

When you migrate from XD to Figma, the biggest practical gap between converters actually shows up in Auto Layout. Color, fonts, and shapes are reproduced reasonably well by most tools, but whether XD’s Stack and Repeat Grid come across as proper Auto Layout in Figma, and how naturally the alignment of those Auto Layout frames is reproduced, is where implementations really diverge.

This article breaks down how XD’s layout concepts (free placement / Stack / Repeat Grid) are handled on the Figma side, walks through Pixel Fine Converter’s Alignment inference and the four modes that control it, and lays out how to decide on manual fixes when inference can’t carry the load.

What you’ll get from this article

• The mapping between XD’s three layout concepts and Figma’s Auto Layout
• The premise that Auto Layout conversion only applies to XD’s Stack and Repeat Grid — free placement stays as absolute positioning
• How Alignment inference works as a three-stage pipeline (“vote → demote → guard against coincidence”)
• When to pick each of the four Alignment inference modes (Off / Strict / Balanced / Native-first)
• The patterns where Alignment inference falls short (e.g. coincidental CENTER alignment), and a practical guide for manual fixes

📝 Introduction — Auto Layout conversion is where converters diverge

Once you’ve converted an XD file into Figma, you may have hit one of these:

• A button group that was a Stack in XD ends up without Auto Layout, so adding a row means manually re-aligning every time
• A button’s interior (icon + label) is Auto Layout, but the alignment is top-left (MIN) when it should be center
• A repeating card row is expanded into separate frames instead of a single Repeat Grid → Auto Layout component, breaking design-token reuse

Each of these is a result of the converter either:

1. Failing to carry XD’s Stack / Repeat Grid information across into Figma’s Auto Layout, or
2. Auto-Layoutifying correctly, but inferring the wrong alignment

Conversely, the better a tool handles both, the more editing speed and maintainability you keep on the Figma side.

📐 XD’s three layout concepts

XD’s layouts split into three broad categories:

In practice, XD designs are built by combining the three — for example, “a Repeat Grid of cards, where each card contains a Stack of icon + text”. The distinction between free placement and Stack / Repeat Grid is what determines how each element is treated during the migration to Figma, so it pays to know which is which in the source file before you start.

🎨 How Figma’s Auto Layout differs

Figma’s Auto Layout is conceptually close to XD’s Stack, but with a few extensions:

• Direction: Vertical or horizontal (same as XD’s Stack)
• Spacing: Fixed value between items, or space-between
• Padding: Independent top/right/bottom/left (more granular than XD’s Stack)
• Alignment: Combinations across primary and counter axes (top-left, center, bottom-right, etc.)
• Sizing: Hug contents / Fixed / Fill container — Figma-specific, no direct XD equivalent

XD’s Repeat Grid has no direct Figma counterpart, so it gets reproduced as “vertical Auto Layout + a single item turned into a Component + duplicated as instances”.

🗺️ Mapping XD layouts to Figma Auto Layout

Pixel Fine Converter applies the following mapping rules:

In other words, the only XD elements that get converted into Auto Layout are those defined as Stack or Repeat Grid. Free-placement elements remain absolutely positioned in Figma. What we call “Alignment inference” is the logic that decides which alignment value (top-left / center / bottom-right / etc., across primary and counter axis combinations) an Auto-Layout-ified frame should adopt — it does not turn free placement into Auto Layout. The next section walks through what that actually does.

🔬 How Pixel Fine Converter’s Alignment inference works

Alignment inference is the logic that decides primaryAxisAlignItems and counterAxisAlignItems for a frame that’s been Auto-Layout-ified, based on its children’s coordinates. It’s built from three techniques, and each mode (next section) decides which combination is active.

Technique 1: Size-weighted voting (Minimize alignment shift)

From the children’s coordinates, we vote on which alignment axis dominates (left / center / right, top / center / bottom). Each element’s vote is weighted by its size, so larger elements have more say. This prevents tiny icons from skewing the alignment of the whole group. Active in Strict and Native-first modes.

Technique 2: Demotion on tied votes (Skip ambiguous auto-layout)

When the vote is tied or close (e.g. LEFT 40% / CENTER 35% / RIGHT 25%), forcing Auto Layout would likely produce visible breakage. In that case we demote and fall back to a plain Frame (layoutMode=NONE). Trading off “this group won’t be Auto Layout” prevents misjudgments. This is an orthogonal toggle that combines with any mode.

Technique 3: Guard against coincidental matches (Guard center alignment)

Sometimes a group has only two children that appear center-aligned — but actually that’s just a side effect of the children being the same size, not a deliberate alignment choice. We detect this and prevent unintended CENTER inference. Active in Strict and Balanced modes.

🎚 Picking among the four Alignment inference modes

From v1.3.0 onward, Alignment inference behavior is controlled via the alignmentInferenceMode mode selector. There are four modes; each one toggles size-weighted voting (Technique 1) and the coincidence guard (Technique 3) in a different combination.

Note that alongside alignmentInferenceMode, there are two orthogonal toggles: Skip ambiguous auto-layout (gives up on Auto Layout when votes are tied, leaving a plain frame) and Preserve cross-axis offset (preserves left margin on MIN-aligned children). They combine with any mode — see Guide: Auto Layout for details.

⚠️ Where Alignment inference falls short — and how to fix it manually

Alignment inference isn’t a silver bullet. Several patterns require manual cleanup.

Pattern 1: Coincidental match patterns

Cases where elements happen to share the same size, making them look CENTER-aligned by accident (commonly seen in parallel button rows, icon clusters, or footer alignments). The coincidence guard built into Strict and Balanced modes catches many of these, but not everything. Inspect the result and revert any unnatural CENTER alignment to MIN manually, or adjust the Alignment property on that frame in Figma.

Pattern 2: Deeply nested Repeat Grid

When Repeat Grids are nested inside other Repeat Grids, structural reconstruction accuracy for the inner repetition unit can drop. After conversion, check the component hierarchy and reorganize into Component → Variant manually if needed.

Pattern 3: Components that need dynamic sizing

Figma’s Hug contents / Fixed / Fill container has no XD equivalent, so converted output defaults to Hug contents. Cases where you’d expect Fill container (text or buttons that should expand to parent width) will need manual sizing changes after conversion.

Pattern 4: Free-placement elements you want to convert into Auto Layout

XD elements that were free-placement stay absolutely positioned in Figma. To organize them as Auto Layout in Figma:

1. Multi-select the elements in Figma
2. Press Shift + A to apply Auto Layout
3. Set the primary direction, alignment, and spacing manually

You can avoid this manual step by converting the elements into a Stack on the XD side before migration — that’s the more efficient approach if you have access to the source file.

🔄 Post-conversion workflow

To get the most out of Auto Layout conversion and Alignment inference, a structured cleanup pass after conversion goes a long way:

1. Convert with Balanced mode: Start with the default
2. Visually scan the artboards: Classify what came across as Auto Layout frames vs. what stayed free placement
3. Fix unnatural alignment: Revert any unintended CENTER inference (caused by coincidental matches, etc.) to MIN on the Figma side
4. Convert free placement into Auto Layout where needed: Manually Auto-Layout-ify any free-placement areas you forgot to Stack-ify in XD (Shift + A)
5. Reorganize the component hierarchy: Tidy Repeat-Grid-derived instances into Component → Variant
6. Adjust sizing: Switch to Fill container / Fixed where appropriate

This loop lets you combine Alignment inference at conversion time with targeted manual fixes to land on a clean Auto Layout structure in Figma.

💬 Frequently asked questions

Q: Many areas aren’t Auto Layout after conversion.

A: Auto Layout conversion only applies to elements defined as Stack (Auto Layout in XD) or Repeat Grid in XD. Anything that was free placement in XD remains an absolutely-positioned Frame in Figma. To make those Auto Layout, you need to either:

1. Stack-ify them on the XD side before converting (recommended), or
2. Manually Auto-Layout-ify them in Figma (multi-select + Shift + A)

Q: Auto Layout alignment came out different from what I intended.

A: Alignment inference decides alignment by majority vote on the children’s coordinates, so intentional CENTER can come out as MIN, or MIN can be misread as CENTER. Re-convert with Strict mode (size-weighted voting plus coincidence guard, both on), or directly adjust the Alignment property on that frame in Figma.

Q: Repeat Grid instances aren’t linked after conversion.

A: We try to detect structural similarity between instances and consolidate them into Components, but when element variation is high they may end up as separate frames. After conversion, manually reorganize into Component → Variant in Figma to restore editing efficiency.

Q: Is Alignment inference available on the Free plan?

A: Free plan operates in Off mode only (no Alignment inference; Auto Layout frames default to MIN alignment). Mode selection (the four modes) and the orthogonal toggles (Skip ambiguous / Preserve cross-axis offset) are Pro features. See Features: Auto Layout conversion for details.

Q: How does Auto Layout conversion compare to Angel Converter?

A: We’ve done a side-by-side comparison in XD→Figma conversion plugins compared. The most reliable approach is to run both on a real XD file of yours and pick the one whose output matches your design.

Q: Are XD elements that are merely “grouped” subject to Auto Layout?

A: No. Pixel Fine Converter reads Stack settings (isContentAware && contentStackType) from XD’s meta.ux data to decide whether to Auto-Layout-ify. XD elements that are only grouped (without being Stack-ified) come across as regular Frames (layoutMode=NONE) in Figma.

✅ Wrapping up

We’ve covered the full picture of converting XD’s layout structure into Figma’s Auto Layout.

Article takeaways

1. Auto Layout conversion is where converters diverge most
2. Auto Layout conversion only applies to XD’s Stack / Repeat Grid — free placement stays as absolute positioning
3. Pixel Fine Converter’s Alignment inference is a three-stage pipeline: vote → demote → guard against coincidence (it operates on Auto-Layout-ified frames to decide their alignment)
4. Four Alignment inference modes (Off / Strict / Balanced / Native-first) plus two orthogonal toggles let you dial in inference strength and coverage
5. Understanding inference’s limits and combining it with manual fixes is the realistic path (manual Auto-Layout-ifying for free placement is part of that)

Just opening an XD file in Figma doesn’t unlock Auto Layout. Stack-ify on the XD side beforehand, pick the right mode at migration time, and clean up alignment and Auto Layout coverage afterward — these three decisions are what determine your editing efficiency in Figma.

Related

• Features: Auto Layout conversion — Formal spec, full parameters, and implementation notes
• Guide: Auto Layout — Full reference for conversion options
• Adobe XD to Figma migration — a practical guide — How Auto Layout fits into the full migration process
• XD→Figma conversion plugins compared — Pixel Fine Converter vs Angel Converter, with Auto Layout among four points
• Three ways to open Adobe XD files in Figma — The first step of migration