Online Tool Store
CSS Border Radius Generator
Builds border-radius with the full eight-value elliptical syntax, collapses it to the shortest shorthand, and reports the spec scaling factor when radii along a side overflow. Resizable preview shows how percentages differ from pixels.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Top left
Top right
Bottom right
Bottom left
CSS
Rendered by your own browser, so the preview is the real thing rather than an approximation. Percentages are relative to the box: horizontal radii to its width, vertical radii to its height — which is why a percentage radius changes shape when the box does and a pixel radius does not.
How to use it
- Drag the corner sliders — the preview is your own browser rendering the real declaration.
- Turn on separate horizontal and vertical radii for elliptical corners.
- Resize the box to see how percentages behave differently from pixels.
- Watch the overlap notice: it tells you when the browser is quietly shrinking your shape.
There are eight radii, not four
Almost everyone writes border-radius with one to four values, and that
only ever produces circular corners. The full syntax takes eight, split by a slash:
border-radius: 10px 20px 30px 40px / 5px 10px 15px 20px;
└─── horizontal ───┘ └─── vertical ───┘
The values before the slash say how far the curve extends along the horizontal edges; those after say how far along the vertical edges. Give a corner different horizontal and vertical radii and it becomes a quarter of an ellipse — which is the only way to get leaf shapes, tickets, tapered cards and asymmetric blobs from a single property.
The rule that makes corners shrink unexpectedly
This is the behaviour worth understanding, because it explains almost every "why does my border radius look wrong" question. If the two radii along any one side add up to more than that side's length, the browser cannot draw them — so it scales every radius on the element by a single factor until they fit.
box 200 × 100
top radii 150 + 150 = 300 > 200 → factor 0.6667
all radii 500 → factor 0.1000
left verticals 80 + 80 = 160 > 100 → factor 0.6250
That last row is the surprising one. Only the left side overflowed, and only vertically — but the factor applies to all eight radii, so 10px horizontal corners on the far side of the box render at 6.3px. Nothing is clamped locally; the entire shape is reduced together so it stays self-consistent. The widget reports the factor and the resulting pixel sizes whenever this kicks in.
The same rule is why the familiar pill trick works. Setting a huge radius like
9999px on a short box overflows massively, so the factor reduces it to
exactly half the shorter side — a perfect semicircular cap, at whatever height the element happens to be, with no arithmetic on
your part.
Percentages resolve against the box
A percentage radius is not a percentage of the other radius or of some overall size — horizontal radii resolve against the element's width and vertical radii against its height, independently.
50% on 100 × 100 → 50px / 50px a circle
50% on 200 × 100 → 100px / 50px an ellipse
The practical consequence is that a percentage radius changes shape as its element resizes and a pixel radius does not. For a card whose height depends on its content, a percentage radius will look different on every card — which is why pixels are the right default for interface work, and percentages are for when you genuinely want the curve to track the box.
Shorthand, and what it costs you
Values run clockwise from the top left, and shorter forms fill in by symmetry:
10px → all four corners
10px 20px → TL+BR, then TR+BL
10px 20px 30px → TL, TR+BL, BR
10px 20px 30px 40px → TL, TR, BR, BL
The tool always emits the shortest equivalent form and says which one it chose. Worth knowing that the collapsing is exact rather
than approximate — 10px 20px 30px 20px genuinely is
10px 20px 30px, but change that last value and all four are required.
What border-radius cannot do
It draws quarter-ellipses, and nothing else. That rules out the continuous-curvature "squircle" used by some operating system
icons, any inward or concave curve, and corners with more than one curve in them. Those need
clip-path, an SVG mask or a border image. If a shape you have seen looks
almost but not quite achievable here, that is usually why.
FAQ
Why has the browser made my corners smaller than I asked for?
Because the radii along one of the sides added up to more than the side is long. When that happens the specification does not clamp the offending corner — it scales every radius on the element by the same factor, so the whole shape comes out proportionally smaller. The widget computes that factor and shows you the size the browser will actually render.
Why did making one corner bigger shrink a different corner?
That is the same rule, and it is the part that feels wrong. The scaling factor applies to all eight radii, in both axes. On a 200 by 100 box with 10px corners, pushing two vertical radii on the left side to 80px each makes them sum to 160 against a 100px side, giving a factor of 0.625 — and your 10px horizontal radii render at 6.3px. Nothing is broken; the browser is keeping the shape self-consistent.
What does the slash in border-radius mean?
It separates horizontal from vertical radii. Everything before the slash sets how far each corner curves along the top and bottom edges; everything after sets how far it curves along the left and right edges. When the two differ the corner is a quarter of an ellipse rather than a quarter of a circle, which is how you get shapes that a four-value border-radius cannot produce.
Why does 50% make a circle sometimes and an ellipse other times?
Because percentages resolve against the box, not against each other — horizontal radii against the width, vertical against the height. On a square, 50% both ways gives four quarter-circles that meet, which is a circle. On a 200 by 100 box the same 50% means 100px horizontally and 50px vertically, so you get an ellipse. That is also why a percentage radius reshapes when the box resizes and a pixel radius does not.
How do the shorthand values map to corners?
Clockwise from the top left: top-left, top-right, bottom-right, bottom-left. With three values the second covers both top-right and bottom-left. With two, the first covers top-left and bottom-right and the second the other pair. With one it applies to all four. The tool collapses your values to the shortest equivalent form automatically and tells you when it could not.
Should I use px or percentages?
Pixels when you want a consistent corner regardless of element size, which is nearly always the right answer for buttons and cards — a percentage radius on a card makes the corners change as the content grows. Percentages when the curve should scale with the box, which is what makes pill shapes and circles work. Note that 9999px is a common trick for a pill, and it works precisely because of the scaling rule above: the browser reduces it to exactly half the shorter side.
How we compare
| Feature | Online Tool Store | Other radius generators | Browser devtools |
|---|---|---|---|
| All eight radii, not just four | ✓ | Rarely | ✓ |
| Warns when the browser scales your radii | ✓ | ✗ | ✗ |
| Resizable box to test percentages | ✓ | Sometimes | ✓ |
| Collapses to the shortest shorthand | ✓ | ✗ | ✗ |
| Preview is the real browser rendering | ✓ | ✓ | ✓ |
| Edits your actual page live | ✗ | ✗ | ✓ |
| Squircles and concave corners | ✗ | ✗ | ✗ |
Devtools will always win for adjusting a real element in place. What this adds is the explanation — the overlap factor, the percentage behaviour and the eight-value syntax — so the declaration you copy behaves the way you expect at other box sizes too. For anything border-radius genuinely cannot draw, reach for clip-path.