CSS workflow
CSS border-radius: elliptical corners and overlap
A rounded corner can have different horizontal and vertical radii. Edit its native CSS visually, then check the same declaration on your real component: shape depends on the border box, not just the numbers you typed.
Content updated: · Maintainer and corrections
Read corners clockwise, then read the slash
Four values run top left, top right, bottom right, bottom left. Values before / are horizontal radii; values after / are vertical radii. Without a slash, both axes use the same list. One value applies to all corners; two repeat opposite corners; three reuse the second value for the bottom-left corner.
A corner is circular only when its used horizontal and vertical radii are equal. If either axis is zero, that corner is square. Native elliptical corners are not superellipses or mathematical squircles; this editor does not generate corner-shape.
Percentages depend on both box dimensions
Horizontal percentages resolve against border-box width; vertical percentages resolve against its height. At 300 × 200px, 50% resolves to horizontal 150px and vertical 100px. A square with 50% corners becomes a circle, while a rectangle becomes an ellipse.
The preview uses a scrollbar-free border box. It may scale down to fit your screen, but target dimensions and copied CSS remain unchanged. Changing the preview size does not export width, height or responsive breakpoints. px and % modes keep separate in-page values; switching modes does not convert or preserve the shape automatically.
One overlap factor scales every radius
When adjacent specified radii exceed their edge length, the browser applies one common factor to all eight radii. Take the smallest of 1, width divided by the top horizontal sum, width divided by the bottom horizontal sum, height divided by the left vertical sum, and height divided by the right vertical sum. A zero sum adds no constraint.
For a 200 × 100px box with all radii set to 80px, the factor is 100 / 160 = 0.625 and every used radius is 50px. The declaration is still border-radius: 80px;. The table explains this simple preview, rounded to two decimals; it is not a general DOM used-value inspector. Browsers can make additional adjustments for scrollbars, outside this preview's model.
Check content, hit areas and visible focus
A rounded background does not automatically clip every descendant. Choose an overflow policy deliberately when content must follow the curve; overflow: hidden can also clip focus indicators or other content. Keep essential controls and a visible focus treatment, and test with real text and zoom.
Rounded borders affect pointer-event boundaries; do not assume the full rectangular corner is clickable. A decorative preview does not establish accessibility compliance. Test the receiving component with keyboard and pointer input, narrow screens and forced colors. Keep border-radius separate from a polygon clip-path when their purposes differ.
Keep editor limits and privacy explicit
The editor accepts radii from 0–9999px or 0–100%, up to one decimal, and integer preview dimensions from 64–640px. It trims surrounding whitespace but rejects blank, negative, non-finite, exponent, unit-bearing and over-precision input. These are editor limits, not CSS limits. Dragging clamps to 0–100%; arrow keys adjust 1 or 10 with Shift, and Escape cancels a drag.
Invalid fields block preview, output and copying without showing stale success. Clipboard failure leaves selectable code. Settings stay in this page's memory without upload, persistence, URL parameters or input-value analytics; normal approved page analytics may still run. The editor does not import arbitrary CSS, mix units, export SVG or animate shapes. Test your supported browsers and real component after copying.
.card {
border-radius: 24px 8px 32px 8px / 12px 8px 24px 8px;
}
.card:focus-visible { outline: 2px solid #315460; outline-offset: 4px; }
/* 200 × 100px: specified 80px, used 50px */
.overlap-example { width: 200px; height: 100px; border-radius: 80px; }Data provenance