Corner radius is not a style choice.

Most teams treat rounded corners as taste — a slider you nudge until it feels friendly, then copy everywhere. But a corner is a curve fitted to a rectangle, and curves inside other curves obey arithmetic. Get the arithmetic wrong and nothing looks broken; it just looks slightly homemade, in a way nobody on the team can name.

Nested corners have one formula

The single most common radius bug is a rounded thing sitting inside another rounded thing with the same radius on both. A card at 24px radius, 16px of padding, and a thumbnail inside also at 24px. It looks fine in isolation. Side by side with a correct version, the wrong one reads as slightly crowded at the corners — the gap between the two curves pinches to nothing at 45° and opens back up along the straight edges.

The fix is a subtraction: inner radius = outer radius − padding. Card at 24 with 16px padding? The inner element wants 8. Padding of 24 inside a 24 card? The inner element is square — radius 0. That's not an aesthetic preference, it's what keeps the two curves concentric: the same distance apart at every point along the corner, exactly like the straight edges already are.

Once you know it, you see the violation constantly: avatar chips inside list rows, image thumbnails inside cards, a rounded input inside a rounded dialog, a device frame inside a rounded screenshot panel. It's also the reason "just use the same border-radius token everywhere" quietly fails — a single token can't satisfy a rule that depends on padding.

The same number is two different corners

Radius doesn't scale with a shape's area, it scales against the shape's shortest dimension. 12px on a 400×280 card is a whisper. 12px on a 32px-tall chip is more than a third of the height — it's most of the way to a pill. Same token, completely different voice.

Two guardrails handle this. First, a radius can never exceed half the short side; past that, renderers clamp it and you silently get a stadium shape instead of the value you wrote. Second, build a small step scale tied to component size rather than one universal value — something like 4 for inline controls, 8–10 for inputs and buttons, 14–18 for cards, 24–28 for sheets and modals, and full-pill only where you mean "tap me." Five steps is plenty. The goal isn't the specific numbers; it's that a component's radius is a function of its size, so a button and a bottom sheet don't claim the same curvature.

A related trap: scaling a design up for export. If you compose a screenshot frame at 1x and render it at 3x, the radius must scale with it. Miss that — because the radius was hardcoded in output pixels while everything else scaled — and your soft 20px corner arrives as a nearly-square 20px corner on a 1290px-wide canvas.

Circular arcs vs. continuous curves

Here's the part that surprises people who've already got the math right. There are two different ways to draw a rounded corner, and platforms disagree about which one they use.

The classic approach is a quarter-circle: the straight edge runs to a point, then curvature jumps instantly to a fixed value and back to zero on the other side. CSS border-radius works this way — elliptical arcs spliced onto straight sides. It's cheap, exact, and at small radii nobody can tell.

The other approach eases curvature in and out, so there's no discontinuity where the corner begins — a superellipse, commonly called a squircle. Apple's platforms use it for app icons, device corners, and most system containers: UIKit exposes it as cornerCurve = .continuous, SwiftUI as RoundedRectangle(cornerRadius:style: .continuous). Figma calls the same idea corner smoothing and gives you a percentage. Flutter ships ContinuousRectangleBorder and, more faithfully, RoundedSuperellipseBorder alongside the ordinary RoundedRectangleBorder.

Two consequences matter in practice. One: a continuous corner reads as tighter than a circular corner at the same numeric radius, because the curve starts earlier and spends longer easing, so switching styles without adjusting the number changes the look. Two — and this is where it bites screenshot work — if you draw a phone body with a plain circular radius and set it beside a real device photo or an Apple-drawn frame, the corners visibly disagree. The circular one looks pinched at the diagonals. That mismatch is the tell that a mockup was drawn rather than measured.

What the curve actually communicates

Radius carries tone before anyone reads a word. Zero reads technical and dense — terminals, spreadsheets, pro tools. Small radii, 4 to 8, read as software: neutral, competent, unremarkable. Larger radii, 16 and up, read consumer and approachable. Full pills read playful and action-oriented, which is why they dominate CTAs and toggles.

None of those is correct in the abstract. What's incorrect is using three of them at once with no rule behind it. That's the real damage in an unconsidered radius: a set of frames where a card is 8, a badge is 20, and a button is 4 doesn't read as "eclectic," it reads as assembled by different people on different days. Consistency here is close to free and it's one of the strongest cheap signals that something was designed.

It matters most where you can see it least

Store listings compound this. Your screenshots are viewed first as small carousel thumbnails, where a 4px radius on a 1290px-wide canvas is invisible and a 60px one dominates the frame. Whatever curvature you chose gets evaluated at a size you never designed at. Before shipping a set, scale it down to about 150px wide and look again: the corners either form a coherent rhythm across the frames or they turn to visual noise, and you'll know within a second which one you have.

Where we sweat this so you don't

Every ShotCanvas template carries a radius scale, not a radius. Device frames, cards, badges, and headline plates derive their corners from the frame's own width and from each other: the screen's radius inside a phone body is literally the body radius minus the bezel, so the two curves stay concentric no matter what size the layout renders at. You pick the template; the arithmetic follows.