Skip to main content

Border Radius Generator

What it does

The Border Radius Generator builds a CSS border-radius value using a slider per corner with a linked/independent toggle. In linked mode all four corners stay equal; in independent mode each one moves on its own. The output uses CSS shorthand when corners match (a single 20px) and longhand when they do not (20px 0 20px 0), so the result is always the cleanest legal form. The preview is a real rectangle at the size you would actually use, not a square thumbnail — proportions matter for radius judgements.

Common situations

You’re building a design system from scratch and need to define the radius scale. Most modern systems pick three to five values (radius-sm, radius-md, radius-lg, radius-full) and stick to them across every component. Picking those values means trying a handful of candidates against real component sizes and committing to what reads consistently — exactly what the visual builder is for.

You’re matching an existing design system’s radius from a screenshot or design file. The Figma file specifies “12px” but the rendered result looks rounder than expected; checking against the actual rendered output reveals subpixel differences worth knowing about before recreating it in code.

You’re building a speech bubble or chat-style component with one sharp corner pointing at the speaker. Per-corner control turns “I want it to lean right with a sharp top-right” into a value you can copy in seconds rather than puzzling over which CSS property maps to which corner.

You’re building a “retro” or “neo-brutalist” layout where strong asymmetric radius is the design language. Cards with one rounded corner and three sharp ones, buttons with rounded top edges only, image frames with diagonal opposites rounded — all asymmetric patterns that need visual tuning, not numerical guessing.

You’re testing whether a component should be a “pill” (radius equal to or greater than half the height) versus a regular rounded rectangle. The transition between “rounded rectangle” and “pill” happens at a specific value relative to the element’s size — sliding past it visually is faster than calculating it.

What you need to know

border-radius accepts up to four values that map to the four corners, starting top-left and going clockwise (top-left, top-right, bottom-right, bottom-left). When all four are equal the shorthand collapses to one value; when corners pair up symmetrically it can use two; otherwise four are needed. Browsers also accept a slash-separated form for elliptical corners (different horizontal and vertical radii) but that is rarely used outside specific decorative cases.

When the radius exceeds half the element’s smallest dimension, the corners blend into each other and you get a circle (or a pill, depending on aspect). Setting border-radius: 50% produces an ellipse if the element is rectangular, a perfect circle if square. That percentage variant is occasionally exactly what you want — particularly for circular avatars that need to scale with the image — but it interacts strangely with non-square sources.

The four longhand properties are border-top-left-radius, border-top-right-radius, border-bottom-right-radius, border-bottom-left-radius. Each accepts either a single value (circular corner) or two values separated by a space (elliptical corner). Most production CSS uses the shorthand border-radius — the longhand is mostly used for animation, where transitioning a single corner is sometimes desired.

Modern design systems treat radius as a named scale, not as ad-hoc pixel values. A typical scale: radius-sm: 4px, radius-md: 8px, radius-lg: 12px, radius-xl: 24px, radius-full: 9999px. Tailwind, shadcn/ui, and most major component libraries follow this pattern. The discipline is that nothing in production should use a raw pixel value — everything maps to a token.

Browser support is universal in 2026. The CSS property has been stable since IE9; nothing modern is at risk. The only edge case is animating border-radius in older Safari, which historically had subpixel rendering quirks during the transition that produced visible jitter — fixed in current versions.

Frequently asked questions

How do I round corners in CSS?

Use the border-radius property. border-radius: 8px rounds all four corners equally. For per-corner control, list four values clockwise from top-left: border-radius: 8px 0 8px 0.

How do I make a circle with CSS?

Use border-radius: 50% on a square element. If the element is rectangular, the result is an ellipse. For images that should always be circular regardless of source dimensions, combine with aspect-ratio: 1 to force the element square.

What’s the difference between border-radius in pixels vs percent?

Pixels are absolute — 8px is always 8px regardless of element size. Percentages are relative to the element’s dimensions — 50% always produces a fully rounded shape regardless of size. Pixels are typical for cards and buttons; percentages are typical for avatars and pills.

Does border-radius work on images?

Yes — apply it directly to the <img> element. Note that without overflow: hidden on the parent, the image content extends past the rounded corner; with border-radius directly on the img, the image clips correctly.

How do I animate border-radius smoothly?

Use a CSS transition on border-radius. The animation is composed on the GPU in modern browsers, so it is performant. For complex animations that change individual corners, use the longhand properties (border-top-left-radius, etc.) so each corner can transition independently.

What border-radius value makes a “pill” button?

Any value equal to or greater than half the button’s height. The convention is border-radius: 9999px, which is large enough to always exceed half the element’s height and renders as a pill regardless of size.

Why does border-radius look pixelated at small sizes?

Browsers anti-alias the curve, but very small radii (1–3px) on low-DPI displays produce visible step artefacts. There is no fix at that size — increase the radius slightly, or accept the rendering. Retina and high-DPI displays do not have this issue.

Can I have rounded corners on only some sides?

Yes — set the unwanted corners to zero. border-radius: 8px 8px 0 0 rounds only the top corners, useful for cards with a tab-style top.

Common problems

Problem: Border-radius is being clipped by a parent element with overflow:hidden.

The radius applies correctly to your element, but the parent’s overflow rules cut it off. If the rounded corners need to be visible, restructure so the parent does not have overflow:hidden, or apply the radius to the parent and let it clip the child. Check the DOM structure rather than fighting the cascade.

Problem: A 50% radius on a non-square element produces an ellipse, not the circle I wanted.

50% is relative to each axis, so a non-square element produces an ellipse by definition. Force the element square first using aspect-ratio: 1 (modern CSS) or width and height set to the same value, then apply the 50% radius.

Problem: Different components have slightly different radius values that look almost-but-not-quite consistent.

This is design-system drift. The fix is institutional, not visual: define a small named scale (3–5 values), document which components use which, and replace ad-hoc pixel values across the codebase. The systems we build absorb exactly this kind of cleanup.

Problem: Animation between two border-radius values flickers in older Safari.

Safari historically had subpixel rendering issues during border-radius transitions. Workarounds include adding will-change: border-radius on the element, or using a transform: scale transition instead. Current Safari versions handle this correctly.

Problem: Asymmetric border-radius values do not render the same in Firefox vs Chrome.

The CSS spec defines exact behaviour, but browsers occasionally differ at extreme values (very large radius on very small elements). For values within reasonable design ranges (0–32px radii on 50px+ elements), all browsers render identically.

Quick guides

Tailwind CSS: Use rounded-{size} utilities. The default scale is rounded-sm (2px), rounded (4px), rounded-md (6px), rounded-lg (8px), rounded-xl (12px), rounded-2xl (16px), rounded-3xl (24px), rounded-full (9999px). Customise the scale in tailwind.config.js to match your design system.

Design tokens (CSS custom properties): Define your scale once at the root: --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px; --radius-full: 9999px. Reference everywhere via border-radius: var(--radius-md). Theme switching becomes a single variable swap.

Native iOS: UIView’s layer.cornerRadius is the equivalent property. SwiftUI uses .cornerRadius() modifiers. Both default to applying to all corners; per-corner control needs maskedCorners (UIKit) or RoundedRectangle(cornerRadius:) shapes (SwiftUI).

Tips

  • 4–8px reads as “barely rounded” and suits dense interfaces. 12–16px is the sweet spot for cards and modals. 24px+ starts feeling decorative.
  • Match radius scale across components. Cards at 12px and buttons at 4px feel inconsistent; cards at 12px and buttons at 8px feel intentional.
  • For pill buttons, use a radius equal to or larger than the button’s height. border-radius: 9999px is the conventional safe value — it always exceeds height and renders as a pill regardless of size.
  • Asymmetric radius is a deliberate signal — speech bubbles, message bubbles, retro-style “chat” UIs. Use it sparingly. Three rounded corners and one sharp creates a strong directional cue.
  • Linked mode is the right default. Reach for independent only when you have a specific reason — the asymmetric shapes are fewer than they look.
  • For circular avatars, combine border-radius: 50% with aspect-ratio: 1 and object-fit: cover to handle non-square source images correctly.

Related tools in this suite

The natural pairing is the CSS Triangle Generator — both use border properties to produce visual shapes, and both come up when building speech bubbles and tooltip arrows. The Box Shadow Generator is the other CSS-effect tool you will tune alongside border radius when shaping any UI surface.

Take it further

A consistent radius scale across an interface is the kind of thing design tokens enforce. The systems we build treat radius as a named scale (radius-sm, radius-md, radius-lg) rather than ad-hoc pixel values — once that exists, radius drift across components stops being possible without a deliberate exception.