Border Radius, Borders, and Outlines: What Survives an Import

Three CSS properties shape the edge of a box: border-radius, border, and outline. In a browser's dev tools inspector they sit right next to each other, practically touching. After an import into Figma, they stop behaving like family. One survives corner by corner but loses a curve Figma can draw and CSS cannot. The other two split along a line CSS already drew, between what counts as a border and what counts as an outline, and that line decides whether a stroke pushes your layout around or just sits there as paint.

If you're rebuilding a page with no source file, knowing which of these three survives, and in what form, saves a manual pass of re-guessing which corners were rounded and which stroke was purely decorative. UnHTML reads a page's own CSS to build these shapes rather than guessing from a screenshot, running entirely on your machine with no page content uploaded. So the mapping below describes exactly what to expect: what border-radius keeps and loses on the way into Figma, how border and outline diverge into two different kinds of stroke, and what to check first once an import lands in your file.

border-radius: the four corners and the slash syntax

CSS border-radius is a shorthand for four longhand properties: border-top-left-radius, border-top-right-radius, border-bottom-right-radius, and border-bottom-left-radius. It takes one to four values, applied in that order. One value sets all four corners. Two values set the top-left/bottom-right pair, then the top-right/bottom-left pair. Three values set top-left, then the top-right/bottom-left pair, then bottom-right. Four values set each corner individually, starting top-left and moving clockwise. MDN documents the same four-corner expansion that any browser's computed-styles panel will show you.

Border-radius also supports a slash syntax for elliptical corners: values before the slash set horizontal radii, values after it set vertical radii. border-radius: 10px / 20px draws every corner as a 10px-wide, 20px-tall ellipse rather than a 10px circle. Percentage values resolve against the box's own width on the horizontal axis and its own height on the vertical axis, which is why a tall, narrow element and a short, wide element can use the same percentage and end up with visibly different curves.

When UnHTML imports a page, each corner's computed radius value maps directly to Figma's independent-corner radius fields, measured in the density-independent pixels Figma uses internally. If the source CSS set four different corner values, all four carry across individually, not averaged, not picked-one-and-done. Figma's own corner radius documentation describes the same independent-corner panel, reached by turning on "Independent corners" in the right sidebar.

What doesn't survive is corner smoothing. Figma calls this effect a "squircle": a continuous curve between a square and a circle, popularized by iOS design, with its own slider in the corner radius panel and a quick iOS preset button that sets smoothing to 60%. CSS has no property that expresses this curve. border-radius only describes a circular or elliptical arc, so every import lands at 0% smoothing, a plain arc, even if the live page rendered with something that approximates a smoother corner. Want the squircle look? Add it by hand after the import. The CSS never had it to give.

Border vs outline, and why only one survives as a shape

CSS keeps border and outline conceptually separate, and the separation matters more after an import than it does on the live page. Border is part of the box model: it has a width, it sits inside the element's outer edge, and changing it changes how much space the element and its neighbors take up. Outline sits outside the border and, as MDN puts it plainly, "outlines don't take up space, so they don't affect the layout of the document in any way." outline-offset can push the outline further out still, and that gap is just as invisible to layout. Nothing else on the page shifts to make room for it.

Figma's current auto layout was built to mirror this split. Figma's own guidance on auto layout and CSS Flexbox states the mapping directly: an inside stroke behaves like a border and is included in layout by default, while a center or outside stroke behaves like an outline and is excluded from layout, even when a frame's "stroke included in layout" setting is turned on. That's a deliberate choice, not an oversight. Figma wants an inside stroke able to push a frame's minimum size the way a CSS border does, and it wants a center or outside stroke sitting on top of the layout without ever being allowed to.

Outside an auto layout frame, the distinction narrows again. Figma's stroke properties documentation states that "a stroke's weight is not included in the layer's overall dimensions" by default, regardless of whether the stroke is aligned inside, centered, or outside. The bounding box shown in the sidebar stays the same size either way. Only inside an auto layout frame, and only if you explicitly turn on "include stroke in layout," does stroke weight start counting toward a layer's dimensions at all.

Practically: a CSS border on an imported element becomes an inside stroke that behaves like the original border inside auto layout. A CSS outline becomes a center or outside stroke that renders correctly as paint but never pushes a sibling element the way a real border would. The shape is right either way. The layout behavior is only right if you knew which CSS property it came from.

What the import keeps, and what it flattens

Lined up side by side, three properties split into keep, convert, and flatten:

• border-radius: kept exactly, corner by corner, including elliptical slash-syntax radii. Converted one-to-one into Figma's independent-corner radius fields.
• Corner smoothing: not kept, because CSS has nothing to carry across. Every import starts at 0% smoothing and needs the squircle slider applied by hand if that look is wanted.
• border: kept as an inside stroke, included in layout the same way the source border was.
• outline: kept as a center or outside stroke, visible as paint but excluded from layout, matching the fact that a CSS outline never affected layout either.

One thing worth checking by hand isn't something the import gets wrong, it's something the source page already decided. If a page set outline: none or outline: 0 on an interactive element, that removal survives into the Figma file exactly as written, because the import stays faithful to the CSS as authored. WCAG 2.1's Success Criterion 2.4.7, Focus Visible, requires a visible focus indicator on anything interactive. A page that already disabled its default focus outline carries that gap straight into your redesign. That's a design decision to revisit, not a bug to report.

One dated fact worth keeping in mind: outline has been Baseline, widely available, since March 2023, and border-radius has been Baseline, widely available, since July 2015. Any reasonably current site you import will have both properties active somewhere on the page. That's exactly why the mapping between CSS and Figma strokes matters for nearly every import, not just an edge case.

Frequently Asked Questions

See the FAQ block served with this article for answers on exact radius fidelity, why an outline becomes a separate shape, and whether a missing focus outline carries over.

Border-radius survives an import corner by corner, including elliptical radii, but loses Figma's corner-smoothing curve, since CSS has no property that describes it. Border and outline both survive too, just as two different stroke alignments with two different layout behaviors: an inside stroke that counts toward a frame's size, and a center or outside stroke that paints the same line without ever pushing anything else on the canvas. After any import, check those two spots first: did the right stroke alignment land on the right element, and does any corner need its smoothing added back by hand.