Border-radius often gets treated as an afterthought: a value typed into CSS per component, usually copied from whatever the last component used. That's how interfaces end up with five slightly different corner roundings and no one able to say why. Radius deserves the same systematic treatment as color or spacing, since it does more communicative work than it gets credit for.
Rounding is a personality decision
Sharp, square corners read as precise, technical, serious: think financial dashboards, developer tools, dense data interfaces. Rounded corners read as approachable and soft: think consumer apps, wellness products, anything trying to feel less intimidating. Neither is correct on its own. The mistake is picking a radius without deciding which impression the product actually wants.
It's also why copying a competitor's radius value rarely works well. It was chosen for their product's personality, not yours.
Build a scale, not one-off values
The same problem that affects font sizes affects radius. Pick values one component at a time and inconsistency follows for free. A small radius token set solves it:
- sm: small controls, checkboxes, tags, small buttons
- md: default, most buttons, inputs, small cards
- lg: larger surfaces, cards, modals, panels
- full: pills and circles, avatars, badges, toggle switches
Four tokens, referenced everywhere, instead of a scattered set of pixel values with no shared logic. When the product's rounding personality changes, it's a token edit, not a find-and-replace across every component file.
Match radius to component size
The single most common mistake: applying the same pixel value to everything regardless of how big the element is. An 8px radius reads as a meaningful curve on a 32px button, but on a 400px-wide card the same 8px looks barely rounded at all. As a rule, radius should scale roughly with the element. Larger surfaces need a proportionally larger radius to produce the same visual effect a smaller radius produces on a smaller surface.
Full/pill radius vs. contained radius
These solve different problems and shouldn't be used interchangeably:
- Full/pill radius (avatars, badges, toggle/switch controls, some buttons): the corner radius exceeds half the element's height, producing a capsule or perfect circle. Reserved for small, discrete controls.
- Contained radius (cards, inputs, modals, larger buttons): a partial curve that softens the shape without fully rounding it off. This is where the sm/md/lg tokens above do their work.
Applying a full/pill radius to something large, a wide card or full-width panel, usually looks wrong. The curve becomes so shallow relative to the element's size that it barely reads as rounded, while the crisp edge the layout needed is gone.
A quick decision guide
- Buttons, inputs, tags: sm–md
- Cards, panels, modals: md–lg
- Avatars, badges, switches: full
- Data-dense surfaces (tables, dashboards): smaller across the board, or sharp corners entirely
Radius doesn't work alone
Rounding and shadow are really one concern: how a surface visually separates from the background. They read together, not independently. A heavily rounded card with a hard-edged shadow looks unfinished; the two need to be designed as a pair. Our companion piece on shadow and elevation systems covers this, or set both up together in the Design Language Studio, where radius and shadow are handled as a single surface-treatment step.
To build and preview a radius scale on its own, use the Radius Builder.
