A border radius generator is a visual CSS tool that turns four chosen corner radii into the shortest equivalent CSS border-radius declaration. The CSS Border Radius Generator lets you label the top-left, top-right, bottom-right, and bottom-left controls separately, choose pixels or percentages, and preview the exact shorthand it will copy. That distinction matters because CSS does not always read corner values in the visual left-to-right, top-to-bottom order you might expect. Four values run clockwise from the top-left; shorter forms reuse matching corners. The generator applies those rules for you and compresses repeated values without changing the selected corner shapes. Its preview uses the generated shorthand itself, so it also helps reveal a mistake in the shorthand before the code reaches a page. In practice, the tool answers a focused question: which border-radius declaration should I paste into my stylesheet? It is not an automatic design system and it cannot decide whether a radius suits a button, card, panel, or responsive component. After copying the result, you still need to test the real element at its actual dimensions, with its border, padding, focus state, overflow behavior, and responsive breakpoints. Everything in the generator runs locally in the browser, so design values are not uploaded or stored.
How border radius maps to a box
CSS border radius rounds the border box of an element, and each of its four corners can have an independent circular radius. This is not merely a background decoration: backgrounds and borders follow the curve, and overflow clipping can follow an inner rounded edge. The MDN border-radius reference documents the property’s syntax and its relationship to the border box. That makes radius both a visual choice and a layout behavior that deserves testing in context.
Manual implementation becomes repetitive because every change must be mapped to the correct value order and checked against the rendered box. The generator removes that edit-preview-copy loop. It presents corners in clockwise order, keeps the chosen values attached to explicit labels, and outputs the equivalent shorthand. Its purpose is narrower than full interface design: it solves corner geometry and serialization while leaving component fit and interaction quality to implementation testing.
Generate and copy a declaration
- Open the generator and enter a radius for the top-left, top-right, bottom-right, and bottom-left corners. Follow the displayed clockwise order so each number is attached to the intended corner.
- Choose pixels for fixed curves or percentages for size-relative curves. The generator accepts px and percentage units and validates the four radii as nonnegative numeric values within a practical range.
- Inspect the live preview at the box dimensions displayed by the tool. Check each corner, the background, the border, and any visible clipping. A preview at one displayed size cannot reveal every result produced by responsive dimensions or surrounding content.
- Copy the compressed declaration, paste it into the component’s stylesheet, and test it with the element’s real width, height, border, padding, focus outline, overflow behavior, and responsive breakpoints. The copied code is the deliverable, but final acceptance depends on the surrounding interface.
The preview is rendered from the same shorthand shown for copying, not from four unrelated longhand properties. This makes order and serialization mistakes visible early. The interface keeps each corner explicitly labeled, so you do not have to memorize CSS mappings while experimenting. No account is needed, and no design values are uploaded or stored; all processing happens locally in the browser.
Why shorthand may contain fewer values
CSS border-radius is a shorthand, so equal or strategically shared corner radii can be represented with fewer entries. The generator compresses repeated patterns into their equivalent shorthand while preserving exactly the corner values you selected. In the table below, A, B, C, and D represent values assigned to the corners; they are explanatory labels, not CSS keywords.
| CSS form | Top-left | Top-right | Bottom-right | Bottom-left | Rule |
|---|---|---|---|---|---|
| One value | A | A | A | A | One radius applies to every corner. |
| Two values | A | B | A | B | The first value covers top-left and bottom-right; the second covers top-right and bottom-left. |
| Three values | A | B | C | B | The middle value is shared by top-right and bottom-left. |
| Four values | A | B | C | D | Each corner has its own clockwise value. |
Four equal corners become one value. Alternating opposite corners become two: the first value covers top-left and bottom-right, while the second covers top-right and bottom-left. A shared top-right and bottom-left can produce a three-value form. If no shorter equivalent applies, all four values remain visible in clockwise order.
This is why control order matters. A row-based reading is misleading: four values mean top-left, top-right, bottom-right, then bottom-left. With three values, the middle value is shared by top-right and bottom-left. Because the preview renders the generated shorthand itself, a misplaced corner or incorrect compressed form is easier to catch before code is copied. Shorter text is a convenience, not a change in the intended geometry.
How units and browser rendering affect results
Pixels and percentages define how a radius relates to the component as it changes size. A pixel radius stays fixed, while a percentage radius is calculated from the dimensions of the border box. These choices therefore answer different design questions rather than acting as interchangeable labels.
| Unit | Behavior when the box resizes | Useful intent | Main consideration |
|---|---|---|---|
| Pixels | The specified curve remains fixed. | Consistent rounding on cards, panels, and controls. | The curve does not grow or shrink with the element. |
| Percentages | The curve changes in relation to the border-box dimensions. | Size-relative pills, ovals, leaves, and asymmetric panels. | The appearance can change substantially with the box proportions. |
On a square, 50% creates circular corners; on a wide rectangle, the same value produces ellipse-like ends. The percentage follows both dimensions of the box, so a shape that looks balanced in one aspect ratio can look different in another.
Browsers may proportionally reduce used radii when adjacent curves would overlap. An extremely large specified value can therefore render smaller than its number suggests. This normalization is standard browser behavior, not an error in the copied declaration. The percentage option allows values beyond 100 because CSS accepts them, although very large values often look identical after normalization.
Zero creates a square corner. Negative radii and non-finite numbers cannot produce a valid declaration. The generator produces one circular radius per corner. CSS also supports elliptical radii with separate horizontal and vertical groups divided by a slash, as defined in the CSS Backgrounds and Borders Level 3 specification, but that advanced syntax is intentionally outside this focused generator.
Patterns to try in real components
- Uniform card: Use one shared fixed pixel radius; 12px to 24px is a practical starting range.
- Pill: Use a large pixel radius or 50%, provided the element has enough horizontal padding.
- Organic panel: Vary all four percentage radii so each corner develops its own curve.
These patterns are starting points, not component rules. A button needs enough internal room for its label and focus treatment. A card may need room around text and media. A panel with overflow may reveal whether clipping follows the inner curve. The generator shapes the box; it does not decide the component’s spacing, accessibility, or visual hierarchy.
Production checks the preview cannot replace
The standalone preview is useful for exploring geometry, but the finished interface supplies the conditions that determine whether a radius works. After copying the declaration, run these checks:
- Check the real width, height, border, padding, focus outline, and every breakpoint where the element changes size.
- Inspect overflow clipping and ensure content does not crowd the curve.
- Watch the usable area at heavily rounded corners and retain appropriate touch-target sizes for buttons and controls.
- Test keyboard focus, overflow behavior, contrast, and target size instead of assuming the rounded preview is complete.
- Do not rely on rounded shape or color alone to communicate meaning.
Very large radii may reduce the clickable corner area, so visual roundness and usability need to be evaluated together. For a concrete example of applying the workflow, see the component-level card walkthrough.
The generator is a production aid, not a replacement for testing in the real interface. Because processing stays local, you can explore several radius patterns without sending design values to a server, then copy only the declaration that survives component testing.
For a deeper look, see Box Shadow Generator for Beginners: A Practical CSS Guide.