The CSS border-radius shorthand reads corners in clockwise order — top-left, top-right, bottom-right, then bottom-left — and a generator that labels every corner explicitly removes the need to memorize that mapping. With four values you see those exact four corners in that exact sequence; with three values the middle one is shared by top-right and bottom-left; with two values the first applies to top-left and bottom-right while the second applies to top-right and bottom-left; with one value all four corners match. The generator also compresses repeated corners into the shortest equivalent declaration, so a value set on all four corners becomes `border-radius: 12px` rather than `border-radius: 12px 12px 12px 12px`. That compression keeps the output readable and mirrors actual CSS engine rules, which means whatever the preview shows is exactly what browsers render when the declaration is pasted into a real stylesheet. Treating the values as a clockwise sentence — four corners in order, two opposite pairs, a shared diagonal, or all the same — prevents the most common corner-order bug, which is assuming the shorthand behaves like padding or margin with a left/right split.
What the shorthand values actually mean
The shorthand saves bytes, but only when the corner each value targets stays in working memory. Once the clockwise rule is internalized, the one-, two-, three-, and four-value forms read like a sequence rather than a lookup table:
| Values | Applied to | Example |
|---|---|---|
| 1 | All four corners | border-radius: 12px |
| 2 | Top-left + bottom-right, then top-right + bottom-left | border-radius: 8px 24px |
| 3 | Top-left, top-right + bottom-left, bottom-right | border-radius: 4px 8px 12px |
| 4 | Top-left, top-right, bottom-right, bottom-left | border-radius: 4px 8px 12px 16px |
The clockwise rule is defined in the CSS Backgrounds and Borders Level 3 specification, and the worked examples in the MDN border-radius reference follow the same ordering. The two-value case is the easiest to misread because it pairs diagonally opposite corners rather than visually adjacent ones — `8px 24px` produces a tighter curve at the top-left and bottom-right and a wider curve at the top-right and bottom-left, not a left/right split. Once that diagonal pattern clicks, the rest of the shorthand composition becomes second nature. A quick way to lock the rule in: read the values aloud when authoring and convert a longhand four-property declaration to the shorthand by listing corners clockwise on paper until the mapping stops requiring conscious thought.
Pixels vs percentages, side by side
Both units produce valid curves; they answer different design questions. Pick pixels when the curve should stay a fixed size across screen widths and breakpoints. Pick percentages when the curve should scale with the box, which is what creates pills, ovals, leaves, and asymmetric organic shapes.
| Aspect | Pixels (px) | Percentages (%) |
|---|---|---|
| Anchored to | An absolute CSS length, independent of the box | The element's border-box dimensions |
| As the box grows | The curve stays the same size | The curve grows proportionally |
| Pill button | Use a large pixel radius | Use 50% |
| Asymmetric blobs | Hard to mix four different curves across breakpoints | Easily mixes 0%, 50%, and 100%+ across corners |
| Border overlap | Browsers cap the rendered curve so adjacent curves fit | Same behavior, often more obvious at higher values |
One practical anchor carries most of the weight: 50% on a square element produces a circle, while the same 50% on a wide rectangle produces an ellipse-like curve on the short axis. That single fact drives most of the "why is my pill not perfectly round?" debugging sessions, and a generator that lets you switch units without rewriting the form makes the difference obvious without extra effort.
How to use the CSS Border Radius Generator
- Enter a radius for each corner in clockwise order — top-left, top-right, bottom-right, bottom-left.
- Choose pixels for fixed curves or percentages for size-relative curves.
- Inspect the preview at the displayed box dimensions and confirm the curve looks the way you intend before copying anything.
- Copy the compressed declaration and paste it into your real component, then test the element at its actual width, height, border, padding, focus outline, and responsive breakpoints.
Each input only accepts nonnegative numeric values, so a typo into a negative number or a non-finite value fails the validation step rather than producing a silent bug. The preview uses the same shorthand the tool outputs, so a serialization mistake is visible on screen before the declaration ever leaves your browser. Following the steps above in this order usually takes under a minute; the more common shape-driven approach, dragging visual handles in an image editor, often confuses developers because the visual intuition does not map cleanly onto CSS corner order.
Reading the compressed output
Compression is the part most generators skip. The CSS Border Radius Generator applies the same shorthand rules the browser engine applies, so the output you see is identical to what your stylesheet will render:
- All four corners equal → one value: border-radius: 16px.
- Alternating opposite corners equal → two values: border-radius: 16px 32px.
- Top-right and bottom-left equal while the others differ → three values: border-radius: 8px 16px 24px.
- All four corners differ → four values: border-radius: 4px 8px 12px 16px.
The same compression also exposes a subtle browser behavior worth knowing about: when adjacent curves would overlap, browsers proportionally reduce the rendered curve so it fits inside the border box. An extremely large specified value can therefore render smaller than its number suggests. This normalization is part of the CSS specification, not a tooling defect, and the preview reflects it because the preview renders the generated shorthand itself.
After you copy: verify in the real component
The generator is a production aid, not a substitute for component-level testing. The compressed declaration has already passed corner-order and compression rules by the time you paste it into your stylesheet; what it has not done is interact with the element's actual layout, including its padding, border, focus outline, hover state, and any responsive breakpoint where the size changes.
Three checks catch the issues that most often slip past a clean declaration.
- Touch targets. Very large radii shrink the clickable corner area. Interactive controls should still meet appropriate touch-target sizes, and the rounded shape should not be the only signal communicating meaning.
- Focus and contrast. A visible keyboard focus outline must remain obvious on rounded controls. Color and shape together should not carry the full weight of differentiation for sighted keyboard users.
- Padding and overflow. A small padding value can cause text to crowd the curve, and overflow: hidden follows the rounded inner edge — usually correct, but worth confirming on long content where the corner clipping shows up.
Three solid starting points carry most real designs: cards between 12px and 24px, pill buttons with a large pixel radius (or 50%, provided the element has enough horizontal padding), and organic panels where all four percentages vary. Each one is quick to dial in with the generator and easy to verify once the declaration lands in the component, and the CSS Border Radius Generator produces both the compressed shorthand and a live preview for every combination along the way.