CSS Position in Figma: Static, Relative, Absolute, Fixed, and Sticky

CSS has exactly five values for the position property: static, relative, absolute, fixed, and sticky. Figma has none of them. What it has instead is auto layout, the option to make a layer ignore auto layout, and a set of resize constraints. Each covers a different piece of what position does in the browser. If you've ever imported a page and wondered why a sticky sidebar landed as a plain static layer, this is why.

The gap shows up most in three situations: redesigning a site that never had a design file, tearing down a competitor's page to see how it's built, and rebuilding a legacy page whose original source no longer exists. In all three, the layers you get back are only as useful as your understanding of which CSS behavior each one used to have. Figma has no way to preserve that information on the canvas itself.

This reference walks through all five values, what each one actually does per MDN and the CSS Positioned Layout spec, and which Figma mechanism, if any, plays the same role. It ends with a property-to-property table for quick lookup, current as of 2026, while the CSS Positioned Layout Module Level 3 spec remains the reference definition for all five values.

Static and Relative: The Two That Reserve Layout Space

position: static is the default. No element needs to declare it, and once declared, top, right, bottom, left, and z-index have no effect on it at all. The element sits exactly where normal document flow puts it.

position: relative also stays in normal flow, but it can be nudged with top, right, bottom, and left. The nudge is visual only. The space the element would have occupied at its un-nudged position stays reserved in the layout, so nothing else on the page reflows to fill the gap.

Figma's closest match for both is the default state of a child inside an auto layout frame. A layer that hasn't been told to ignore auto layout follows its parent's layout rules the same way a statically or relatively positioned element follows normal flow, and it keeps its reserved space the same way too. There's no separate "static" or "relative" toggle in Figma, because auto layout already assumes that behavior by default. For the flex-specific side of that mapping, CSS Flexbox to Figma Auto Layout works through justify-content, align-items, and gap property by property.

Absolute Positioning: Containing Blocks in CSS vs Ignore Auto Layout in Figma

position: absolute takes an element out of normal flow entirely. It's positioned against the nearest ancestor whose own position isn't static, or against the page's initial containing block if no such ancestor exists. Nothing is reserved for it in the layout, and unless a width or height is set, it sizes itself to its content.

Figma's version of this is a layer set to ignore auto layout, exposed in the plugin API as layoutPositioning: ABSOLUTE. The layer stays nested inside its parent frame, but it gets explicit x, y, width, and height values instead of following the parent's layout rules. That's the same trade CSS makes: still inside a containing structure, but no longer governed by it. Figma's own constraint system (left, right, top, bottom, center, scale) only becomes available once a layer has ignored auto layout, mirroring how an absolutely positioned CSS element still measures its offsets against a containing block even after leaving the flow.

Not every imported frame converts cleanly to auto layout. When the captured geometry can't be reproduced that way, say overlapping siblings or layout driven by script rather than CSS, UnHTML falls back to absolute positioning for that frame on its own. The result is never worse than a plain layer-for-layer copy of what the page rendered.

Absolute positioning in CSS is also the mechanism behind most badges, tooltips, and modal overlays, since none of those elements should push surrounding content around when they appear. The same holds in Figma once a layer ignores auto layout: it can sit on top of, or partly outside, its parent frame without disturbing any sibling's position. The difference is that a CSS element sized only to its content can end up any width depending on what's inside it, while a Figma layer always carries an explicit width and height the moment it's placed, auto layout or not. That's one of the small but real gaps an import report exists to surface: a width: auto element in the source page becomes one fixed number in Figma, current as of the capture, not a rule that keeps recalculating.

Fixed Positioning: Viewport Anchoring and Why Figma Can't Simulate Scroll

position: fixed behaves like absolute, with one difference. Its containing block is the viewport itself, or an ancestor with a transform, perspective, or filter property set to something other than none. A fixed element doesn't move when the page scrolls, and in paged media it repeats identically on every page.

Figma has no equivalent, because a Figma frame isn't a scrolling viewport. There's nothing to anchor against, since nothing scrolls under the layer in the first place. In practice, the cleanest way to handle a fixed navigation bar or persistent footer after import is to treat it as its own top-level frame rather than expecting it to sit inside the page's main auto layout stack, then reconnect the scroll behavior in code.

The two most common fixed-positioned elements on a real page are a top navigation bar and a cookie or consent banner. Both tend to import in a visually correct spot even though the underlying CSS behavior is gone. Worth flagging to whoever owns the eventual rebuild: the layer looks right at the scroll position where the page was captured, but nothing in the Figma file records that it was meant to stay in that spot at every other scroll position too.

Sticky Positioning: The Value With No Figma Equivalent

position: sticky is the trickiest of the five. It behaves like relative until the user scrolls past a defined threshold, then sticks to a position within its nearest scrolling ancestor. It needs at least one of top, right, bottom, or left set to a non-auto value on a given axis to engage at all. Per the CSS Positioned Layout spec, if only top is set and bottom stays auto, the element will only ever shift downward, never upward. Like relative, it reserves its layout space; unlike absolute and fixed, which don't.

There's no scroll simulation on a Figma canvas, so a sticky-positioned element imports as a static layer every time. That's not a bug in the conversion. It's a structural gap: Figma frames don't scroll the way a browser viewport does, so there's nothing for a "stick here" instruction to attach to. The import report is the place to check for any position: sticky declarations that need to be re-wired once the design goes back to code.

Sticky headers on data tables and sticky section navigation on long documentation pages are the two places this comes up most, since both rely on the element staying visible only after the user has scrolled a specific distance, not from the very top of the page. A reviewer working from the imported Figma file alone has no way to tell, just by looking, that the table header was ever meant to detach from its row and float at the top of the viewport. Cross-checking the import report against the live page, or against the original CSS if it's still available, is the only reliable way to catch every sticky declaration before the rebuild ships.

CSS Position to Figma: A Property Reference Table

Grid-based layouts raise a related but separate question. CSS Grid properties like grid-template-columns and grid-area don't map onto position at all. CSS Grid to Figma: What Survives the Conversion to Layers covers that mapping in the same property-by-property format.

Conclusion

Figma doesn't have a position property, but four of the five CSS values still have a working equivalent. Auto layout covers static and relative, ignoring auto layout covers absolute, and a separate top-level frame is the practical answer for fixed. Sticky is the one true gap, since nothing in Figma reacts to a scroll event. When a conversion can't be made cleanly, the right move is to fall back to absolute positioning rather than guess, and record the fact in an import report so nothing gets lost silently.