CSS Grid to Figma: What Survives the Conversion to Layers

CSS grid maps onto Figma's grid auto layout flow almost property for property. Tracks become tracks. Spans become spans. Gap becomes gap. Two CSS-only ideas, grid-template-areas and subgrid, don't have a native Figma equivalent, so they get rebuilt or flattened instead. This reference walks through what carries over directly, what doesn't, and what happens when an imported grid is too complex to reproduce as a working layout.

How CSS grid tracks become Figma tracks

A page built with display: grid lands in Figma as a frame set to the grid auto layout flow. Most of what defines that grid in CSS has a direct home in Figma's grid controls. Figma's grid auto layout organizes a frame into rows and columns, called tracks, the same way grid-template-columns and grid-template-rows do in CSS. An object that spans multiple cells in the source, set with grid-column or grid-row, becomes an object with a Column span or Row span value in Figma. You get there by setting the object to fill container, then resizing it across cell edges.

The rest of the everyday properties carry over almost as cleanly:

One difference is worth flagging: CSS justify-items and align-items set alignment for the whole container at once, while Figma applies that alignment per object inside its cell. The visual result usually matches, but an imported grid can end up with each object holding its own alignment setting instead of one rule living at the frame level.

The fr unit is easy to miss, so it earns its own callout. In CSS, 1fr 2fr splits available space one third to the first column and two thirds to the second. In Figma, that same ratio comes from setting a track to fill container rather than a fixed size, so a column that used fr in the source CSS should come in resizing with its siblings instead of staying a fixed width. As of the current caniuse dataset, CSS grid has 96.89 percent global browser support, full support since Chrome 57, Firefox 52, and Safari 10.1. Almost every page a designer imports today is working from real CSS grid, not a flexbox or table fallback.

What CSS grid has that Figma auto layout doesn't

Two CSS grid concepts don't have a native Figma counterpart. Knowing which two saves time re-checking the import.

grid-template-areas. CSS lets an author name regions of a grid with ASCII art syntax and place items by area name rather than by row and column number. Figma's grid auto layout has no equivalent naming system. When a page uses grid-template-areas, the import rebuilds each item's position as an explicit column and row span instead. That reproduces the layout, but it loses the readable area-name mapping a developer would see in the CSS.

subgrid. MDN's CSS grid reference describes grid-template-columns: subgrid as a way for a nested grid to inherit its parent's tracks, so items in the child align to the parent's grid lines automatically. Figma has no subgrid concept. A subgridded layout comes in as two independently tracked grid frames, a parent and a nested child, each with its own gap and padding, per Figma's guide to auto layout. The two frames won't stay aligned to each other the way they did in the browser. That alignment has to be rebuilt by hand.

grid-auto-flow, the property that controls how CSS places items falling outside the explicit grid, doesn't carry over as a named setting either. Figma approximates the same left-to-right, top-to-bottom placement on its own, with automatic reflow when an object is removed. But the implicit track sizing that grid-auto-rows and grid-auto-columns control in CSS has no explicit field to check afterward.

When the import can't reproduce the grid

Every capture-to-Figma workflow eventually hits a frame it can't rebuild as a working grid. Usually the CSS relies on something Figma's layout model doesn't have a slot for: grid-template-areas combined with overlapping regions, say, or a subgrid nested several levels deep. When that happens, the sound approach is a fallback to absolute positioning. The object keeps its captured size and location, but it stops behaving like a responsive track and has to be treated as fixed.

UnHTML follows exactly this pattern when it converts a page. It maps flex and grid layouts from the page's actual CSS into Figma's native auto layout, and when a frame can't reproduce the captured geometry, it falls back to absolute positioning on its own rather than guessing at a broken grid, with the swap noted in the import report. That same report also logs font substitutions. A missing font defaults to Inter, and because grid cells are sometimes sized around a specific font's metrics, a substituted font can shift how a row or column reflows even when the grid structure itself imported cleanly.

None of this makes the result a pixel-exact clone of the original page. It isn't meant to be one. grid-template-areas and subgrid are the two places a designer should expect to spend a few minutes rebuilding relationships that CSS expressed for free. Everything else in the table above should already be sitting where it belongs.

A quick checklist for CSS-grid-heavy pages

A few checks take most of the guesswork out of reviewing a grid import:

1. Search the source CSS for grid-template-areas first. If it's there, expect the imported frame to hold explicit spans instead of named regions, and expect to lose the readable mapping between a region's name and its content until you relabel layers yourself.
2. Search for subgrid next. A subgridded section comes in as a parent frame and a child frame with separate tracks. Check that the two still line up visually, and nudge the child's gap or padding if they've drifted apart.
3. Check any column or row that used fr. Confirm the corresponding Figma track is set to fill container, not a fixed width, or resizing the frame later won't reflow the way the original page did.
4. Open the import report before touching layers. Both a font substitution and an absolute-positioning fallback show up there, and either one can explain a row that looks slightly off before you start hunting for the cause.
5. Treat justify-items and align-items as a per-object check, not a per-frame one. Because Figma applies that alignment to each object inside its cell rather than once at the container level, changing one item's alignment won't ripple to its siblings the way editing the CSS rule would.

None of these steps require touching the CSS itself. They're the same five things worth checking on any CSS-grid-heavy import, whether the grid came from a marketing page, a dashboard, or an editorial layout with several nested regions.

Conclusion

Most of what a CSS grid layout does has a one-to-one home in Figma's grid auto layout: tracks map to tracks, spans map to spans, gap maps to gap, and the fr unit maps to fill container sizing. The two real gaps are grid-template-areas, which loses its area names and gets rebuilt as spans, and subgrid, which comes in as separate nested frames instead of one aligned system. A page that leans on either one is the page worth double-checking first after an import.

For the same property-by-property breakdown applied to flexbox instead of grid, see how CSS flexbox maps to Figma auto layout. UnHTML runs this exact grid-to-auto-layout mapping on real pages, and its pricing covers a free tier capped at 500 layers plus a one-time Pro upgrade that removes the cap.