Four numbers in, one declaration out, and still border-radius produces bugs in review.
The causes are predictable: corner order, unit choice, and a clamping rule that fires
when adjacent radii overlap. We ship a border radius generator, and its own presets
demonstrate all three, including one preset whose label overpromises.
Corner order and the shorthand rule
The four values run clockwise from the top left: top left, top right, bottom right,
bottom left. Our generator exposes one slider per corner in exactly that order.
The output follows a collapse rule. When all four corners hold the same value, the tool
emits a single-value declaration:
border-radius: 16px;
Move any one corner away from the others and the output expands to the four-value form:
border-radius: 12px 16px 8px 16px;
The shorthand also accepts two values, opposite corners paired, and three values, with
the fourth mirroring the second. The generator never emits those forms, it collapses or
expands only, so a two-value declaration in your codebase came from a human.
The four presets and what they emit
The tool ships four preset buttons, each writing four pixel values:
| Preset | Values emitted |
| Pill | 100, 100, 100, 100 |
| Circle | 50, 50, 50, 50 |
| Leaf | 0, 50, 0, 50 |
| Ticket | 10, 10, 50, 50 |
Leaf zeroes the left corners and rounds the right ones by 50 px, which reads as a leaf
on wide, short elements. Ticket pairs small top radii with large bottom radii, the shape
coupon cards use.
The clamping rule
Browsers refuse overlapping corner curves. When the radii of two adjacent corners sum to
more than the side between them, every radius scales down by one factor: the smallest
ratio of side length to radii sum, computed across all four sides, multiplies all radii.
Work the pill preset as the example. An element 300 px wide and 60 px tall with four
100 px corners cannot honor those values, because the left side holds a top-left plus
bottom-left sum of 200 against a side of 60. The ratio for that side is 60 divided by
200, so 0.3, and it is the smallest. All radii scale to 30 px, exactly half the height,
and the element renders as a stadium. The clamping is why the pill preset works at any
element size despite shipping a fixed 100 px value.
Why the circle preset is not always a circle
A perfect circle needs each radius at half the shorter side. The circle preset emits
50 px, which is half of a 100 px side and nothing else. The generator previews presets
on a fixed 200 by 200 px element, so the circle preset shows a rounded square with 50 px
corners there, while the pill preset at 100 px renders as a true circle on that same
preview, because 100 is half of 200.
The output is pixel-only by construction, and that is the honest limitation of the tool.
A radius that survives resizing needs a percentage, and the true responsive circle is:
border-radius: 50%;
No preset emits that string. When you need a circle at any size, edit the copied value
to 50 percent yourself.
Three more limits to plan around
The sliders cap at 100 px, so a deliberate 160 px radius on a large card means typing
the final value by hand. The unit is always px, never em or rem, so corner curves do not
scale with your type system unless you convert them. Linked mode is on by default, and
moving any slider writes all four corners, so unlink before shaping a single corner, or
your three careful settings vanish on the first drag.
A deterministic workflow for corner values
1. Decide the element before the radius: exact width, height, and whether either can
change across breakpoints.
2. Fixed-size element: compute half the shorter side, use that in px for a circle, and
anything up to that value is safe from clamping.
3. Resizable element: use 50 percent for circles and large px values for stadium shapes,
letting clamping produce the curve.
4. Asymmetric shapes: unlink the corners, set the top pair and bottom pair separately,
and read the four-value output against the clockwise order to confirm which value
landed on which corner.
5. Paste the copied declaration into your CSS, then check the rendered result at your
smallest and largest element size, since clamping changes the shape between them.
Checklist before you commit corner values
- You know the clockwise order and can name the corner behind each value.
- Equal corners collapse to a single value in the output you pasted.
- Circle needs 50 percent, or a px value equal to half the shorter side.
- Pill and ticket shapes rely on clamping, and you checked them at the smallest element
size.
- Single-corner edits happen with linking off.
- You replaced px with rem or percent where your design scales with type.
Border-radius fails quietly: the declaration is valid, the corners are just not the ones
you meant, or clamping has reshaped them at a different size. The generator makes the
arithmetic visible, and the checks above catch the quiet failures.
Which shape broke on resize in your last project? Build it in the
[border radius generator](https://webrecast.com/en/border-radius-generator) and compare
the emitted values at both element sizes before you paste.
