Border radius generator with eight grips, not four

Put an absurdly large length on every corner — 9999px is the convention — and let the overlap rule solve it for you. The browser scales the radii down until no side is over-subscribed, so 9999px on a 200×48 button resolves to exactly 24px per corner and re-resolves correctly the moment the label wraps to a second line. Using 50% instead looks identical on a short button and wrong on a wide one: 50% of a 400px width is a 200px horizontal radius against a 24px vertical one, so the ends flatten into stretched ellipses rather than staying semicircular.

Because the two axes of a percentage radius resolve against different dimensions: horizontal radii are a percentage of the border box's width, vertical radii a percentage of its height. On the 320×240 default here, 50% means 160px across and 120px down, and a corner whose semi-axes differ is a quarter of an ellipse by definition. A true circle needs either a square box or an absolute length equal to half the shorter side.

It separates the four horizontal radii, written before it, from the four vertical radii, written after it. Every corner is really two lengths — border-top-left-radius on its own takes both — so the complete form is eight numbers, a b c d / e f g h, corners running clockwise from top-left on each side of the slash. Omit the slash and both axes take the same number, every corner becomes a quarter-circle, and the shape can only ever be a rounded rectangle; that single omission is why most generators cannot draw a blob.

The overlap correction is global, not per corner. CSS Backgrounds and Borders Level 3 §5.5 says that if the two radii sharing any one side add up to more than that side is long, the browser computes f as the smallest ratio of side length to radius sum across all four sides, then multiplies every one of the eight radii by f. So a bottom-left corner set past the width of the box drags the top two corners down with it. The panel here prints f live, which is usually the fastest way to work out why a value you typed is not the value being drawn.

border-radius clips the element's own background, border and box-shadow, and nothing belonging to its children. Add overflow: hidden — or overflow: clip, which does the same without creating a scroll container — to the rounded parent, or give the img the same radius directly. Safari has a long-standing habit of leaking square corners when the clipped child is transformed or animated; forcing the parent onto its own layer with isolation: isolate, or masking it with -webkit-mask-image: -webkit-radial-gradient(white, black), is the usual repair.

Yes — the eight radii interpolate independently, so a transition between two very different shorthands morphs corner by corner and axis by axis, and mixing px with % works anywhere calc() interpolation is supported. It costs a repaint on every frame, though, because the corner geometry changes rather than the compositing: one hero blob breathing over 12 seconds is free, forty list rows doing it on hover is where the frame budget goes. Animating the shape on a decorative pseudo-element keeps the repaint off the element carrying your text.

Outer radius minus the distance between the two edges, floored at 0 — a 16px card radius with 8px of padding wants 8px inside it. Concentric curves that share a centre look right; two curves of the same radius at different offsets read as a mistake even when nobody can say why. The browser already applies this rule to borders on its own: the inner edge of a 6px border inside a 4px radius is drawn square, because the subtraction went negative.