Corner Radius

Before this value had a name, conversations about corners happened entirely in adjectives. A designer would say "round that off a little more," the engineer had no idea how much "a little" was, and the revision came back wrong again. Three rounds later both sides finally discovered that one of them had 4 pixels in mind and the other had 12.

The problem grows with the number of screens. Buttons on the settings page end up at 6 pixels, buttons on the dashboard at 10, and the input fields on the checkout page stay square. Users never count those numbers, but moving between screens they sense that something isn't lining up. The product starts to look less like one company's work and more like screens built by separate teams and stitched together.

Corner radius is that conversation moved onto a number. Calling roundness a value rather than an adjective means the design file and the code point at the same thing, and fixing that value to a handful of options means the corners keep the same expression even after the product grows to a hundred screens.

You specify the radius of a circle to be cut into each corner, in pixels or a similar unit, and the corner gets carved to match that circle exactly. Zero is a square corner, and the larger the number, the rounder it gets. Think of it as a single dial running from square to circle.

Three rules are worth knowing.

1. The element's size sets the ceiling. Once the radius reaches half the shorter side, that side becomes a complete semicircle. Give a 40-pixel-tall button a radius of 20 and both ends turn into a pill; push it to 30 and nothing more happens. Do the same on a square and you get a circle.
2. The same number looks less round on a bigger element. Eight pixels is noticeably round on a 32-pixel badge and reads as almost square on a 600-pixel card. That's why teams pair the value with a scale: small values for small elements, larger ones for larger elements.
3. Nested corners get calculated from the inside out. When a button sits inside a card, the outer radius has to equal the inner radius plus the padding between them, otherwise the two curves don't run parallel. An inner button at 8 with 16 of padding puts the card at 24. Set both to 8 and the outer corner turns more sharply than the inner one, which reads as a gap opening up between them.

Rather than allowing any number, teams fix a few steps — something like 0, 4, 8, 16, and one deliberately huge value. That last one is a convention meaning "always a pill or a circle," whatever the size. The reason for fixing steps is the same reason a spacing scale reduces gap values to a short list: when the choices are infinite, every screen accumulates a slightly different one.

The chosen values get names as design tokens — the shared unit that gives a value a name so the design file and the code can both refer to it, the same way colors and spacing do. With radius-md in the design file and the same name in code, changing the roundness of the entire product later means editing one token.

A design system records which step each part uses. Buttons at 8, cards at 16, modals at 20, avatars fully round — write that down and whoever builds the next screen doesn't have to decide again.

It's also a lever for brand impression. Corners near square read as precise and tool-like; large radii read as soft and approachable. That's where the pattern comes from where finance dashboards and admin consoles use small values while consumer apps use large ones. Move one token from 4 to 16 and the whole product feels different without a single screen being redrawn.

On the engineering side it's one CSS property, border-radius. The four corners can take different values, too: a sheet that slides up from the bottom of the screen rounds only its top two corners and leaves the bottom square, which is what makes it read as attached to the edge. Since the value in the design file transfers to code unchanged, it's one of the few things that needs almost no explanation at handoff.

"This card is at 12 but the token says 16."

One screen has drifted outside the steps the system defines, and it should be brought back.

"Should the button go fully rounded, or stay at 8?"

A choice between turning it into a pill and keeping the current step.

"The modal's inner button radius is making the corners look off."

Two nested curves aren't running parallel, and that mismatch is what's visible.

Pagedeck keeps four steps: 0, 4, 8 and 16. The discussion opened when Noa drew a new pricing page and used 24 on the highlighted card, and Theo pointed out that the value doesn't exist in code, so a new token would have to be created.

Noa's reasoning was that the card is larger than the others, so 16 doesn't look round enough on it. Instead of adding a step, the two settled on keeping the card at 16 and separating it with a shadow. Adding a step means the next person has to judge which cards deserve 24, and once that judgment varies by person, four months later the screens are back to carrying a different value each.

Many people treat this as a matter of taste with no right answer. Framed as round versus square, there genuinely isn't one, so the conclusion is understandable. But the question that actually bites isn't which value looks better — it's how many values exist inside one product. Either 8 or 12 is fine; having both is the problem. Leave it to individual preference because "there's no right answer" and a year later six values are mixed across the screens, and at that point nobody can rule on which one is correct, so every screen has to be reviewed again.

The other common mistake is assuming that rounder reads friendlier, so raising the number is an improvement. Large radii do soften the impression, but the effect differs by element. A radius of 20 on a 40-pixel button makes a pill that clearly invites a press; the same 20 on table rows or input fields blurs the boundaries and makes it hard to tell where one field ends. Add nesting on top of that and a button's curve inside a card runs out of step with the card's own curve, so the screen ends up looking messier rather than softer. Before raising a value, look at the size of the element it applies to and at what sits inside it.