Border Radius Generator for Mobile UI

A border radius generator helps you set a mobile radius scale without guessing: start with 8 pt/dp for small controls, 16 pt/dp for cards, and 28 pt/dp for sheets; make a nested element’s radius equal to its container radius minus the shared padding. Use full-pill corners at half a chip’s height, not a token. Choose iOS continuous corners for iOS surfaces and circular rounded corners for Android and cross-platform surfaces. Sharp radii read utilitarian; softer radii read consumer-oriented.

Key takeaways

• •Set nested radius to outer radius minus the padding between both edges.
• •Use 8, 16, and 28 pt/dp as a deliberate three-step starting scale.
• •A full-pill chip uses a radius equal to half its height.
• •SwiftUI supports continuous rounded rectangles through RoundedRectangle style .continuous.
• •Use iOS continuous curves deliberately; do not mix them accidentally with circular corners on one screen.

This guide is for mobile UI/UX designers, founders, and engineers who already work with iOS points, Android dp, or cross-platform component tokens.

Time: 25 minutes · You'll need: A screen containing a chip, card, and bottom sheet, Figma, Sketch, or another mobile UI editor, An iOS simulator or device preview, An Android emulator or device preview, floow.design Border Radius Generator for final curve and code checks

What's on this page

1. •Choose the brand signal before setting tokens
2. •Set a three-step corner radius UI scale
3. •Make nested rounded corners app design concentric
4. •Treat full pills as geometry, not a scale token
5. •Match iOS curves and circular corner behavior
6. •Preview and hand off the border radius mobile spec
7. •Reference table

• •Common mistakes
• •FAQs

Set a mobile corner radius scale step by step

1. Choose the brand signal before setting tokens

Pick the intended personality from the product category, then apply it consistently to every surface. A finance, logistics, or enterprise operations app can begin with the sharper end of the scale: 8 pt/dp cards and restrained 16 pt/dp sheets. A consumer shopping, wellness, or social app can use the softer 16 pt/dp card and 28 pt/dp sheet values defined in this guide.

Do not use radius to solve hierarchy by itself. A 28 pt/dp card in a dense account-settings screen can look toy-like when the task needs compact rows and clear boundaries. Conversely, an 8 pt/dp radius on a full-bleed consumer offer may feel more utilitarian than the brand intends. Write the decision into the component token name, such as radius.card = 16, rather than setting different values by eye on each screen.

Tip: Compare one representative screen at 100% scale; differences of 4 pt/dp are easy to miss in an isolated component.

2. Set a three-step corner radius UI scale

Create exactly three non-pill tokens as a starting system: small = 8 pt on iOS and 8 dp on Android, medium = 16 pt/dp, and large = 28 pt/dp. Assign small to compact controls, input fields, and any non-pill tag treatment. Assign medium to cards, list-group containers, and modal content blocks. Assign large to bottom sheets and prominent full-width surfaces.

Keep the same token roles across platforms even though iOS measures in points and Android measures in density-independent pixels. A settings card should therefore use the medium token on both platforms, not 12 pt on iOS and 16 dp on Android because those numbers happen to be common in separate libraries. This is a project scale, not an Apple or Google requirement; adjust it only after reviewing the chip, card, and sheet together on a target device.

Tip: If a component needs a fourth non-pill radius, first test whether it is actually a card, sheet, or compact control using the wrong component token.

3. Make nested rounded corners app design concentric

Calculate every inset surface manually with this rule: inner radius = outer radius − padding. For a 16 pt/dp card containing an inset panel with 4 pt/dp padding on every edge, set the panel radius to 12 pt/dp. The two curves then share the same visual center and read as parallel contours rather than two unrelated rounded rectangles.

Use the padding that separates the two curved edges, not the text padding inside the child. A 28 pt/dp bottom sheet with a 16 pt/dp inset card therefore gives that card a 12 pt/dp radius. If the calculation reaches 0, use square inner corners; do not force a 4 pt/dp curve that breaks the geometry. Check this at the top corners first, where a sheet, card, image, or selected-state container often makes the mismatch obvious.

Tip: Apply the subtraction rule to image masks and selected-state fills too; they are nested surfaces even when they contain no text.

4. Treat full pills as geometry, not a scale token

Set a chip, segmented-control option, or compact status label to a full pill when its radius equals half its rendered height. A 32 pt/dp chip uses a 16 pt/dp radius; a 40 pt/dp filter chip uses a 20 pt/dp radius. This is why pills need no dedicated small, medium, or large radius step: their radius is derived from the component’s height.

Do not call every rounded control a pill. An 8 pt/dp tag can be appropriate when it needs to align visually with compact input fields, while a pill can make dense metadata labels too bubbly. On iOS and Android, verify the final rendered height after accounting for type, vertical padding, and minimum touch-target treatment. Derive the pill radius from that final height, not from an early design-file frame that may change during implementation.

Tip: Keep the chip’s fill, border, pressed state, and focus indicator on the same pill geometry; mismatched state radii are especially visible during taps.

5. Match iOS curves and circular corner behavior

Use a continuous corner curve for iOS surfaces when the app follows the native iOS visual language. In SwiftUI, use RoundedRectangle(cornerRadius: 16, style: .continuous) rather than the default circular style for a medium card. The continuous curve has a squircle-like transition that appears less abruptly rounded near the straight edges than a circular arc.

For Android Compose, Material-based shapes, CSS previews, and many cross-platform renderers, use ordinary circular rounded corners unless your renderer explicitly supports a continuous curve. A RoundedCornerShape(16.dp) is a circular-corner choice. Do not compare only the numeric value: a 16 pt continuous iOS card and a 16 dp circular Android card can look different at the corner transition. If one shared brand demands identical geometry, test actual platform rendering rather than assuming matching token names guarantee matching curves.

Tip: Avoid placing a continuous iOS card beside a circular custom image mask on the same screen; the mismatch is more noticeable than a 2 pt/dp token difference.

6. Preview and hand off the border radius mobile spec

Build one reference screen with a 32 pt/dp pill chip, a 16 pt/dp card, and a 28 pt/dp bottom sheet. Add one nested example: place a 12 pt/dp inset surface inside the 16 pt/dp card with 4 pt/dp edge padding. Inspect it at device size, then compare the iOS continuous and circular versions before recording the platform decision in the component specification.

You can complete this manually by documenting the three tokens, the inner-radius subtraction, the pill-height rule, and the curve style in your design system. For final implementation handoff, use floow.design’s free Border Radius Generator at /free-tools/border-radius-generator to shape corners independently, preview the iOS continuous curve, and export the chosen values to CSS, SwiftUI, Compose, or Flutter. Export only after the visual review; code should encode the approved geometry, not choose it.

Tip: Include one nested-card reference in the handoff file, because token lists alone do not show whether engineers applied the subtraction rule.

Reference table

Starter mobile radius token scale

Do it with the free Border Radius Generator

Shape each corner independently, preview the iOS continuous curve, and export to CSS, SwiftUI, Compose or Flutter.

Open the Border Radius Generator → — free, no sign-up.

Common mistakes

Using the same 16 pt/dp radius for a card and its inset panel.

Subtract the edge padding from the outer radius. A 16 pt/dp card with 4 pt/dp inset padding needs a 12 pt/dp inner radius.

Adding a fixed 16 pt/dp token for every chip.

Use half of the chip’s final height for a full pill. A 40 pt/dp chip needs a 20 pt/dp radius.

Copying a numeric iOS radius into Android without checking the curve.

Check continuous iOS rendering against circular Android rendering at target size. Match the visual result, not only the token number.

Using a large sheet radius on every card to make the interface feel friendly.

Reserve the 28 pt/dp large token for sheets and major surfaces. Use the 16 pt/dp medium token for ordinary cards.

Frequently asked questions

What is the nested corner radius rule in mobile UI?

The nested corner radius rule is inner radius = outer radius − the padding between the two curved edges. For example, an inset panel inside a 16 pt/dp card with 4 pt/dp surrounding padding should have a 12 pt/dp radius. This creates concentric curves and prevents the inner corners from looking pinched or accidental.

What border radius should I use for mobile cards and bottom sheets?

Use 16 pt/dp for standard cards and 28 pt/dp for bottom sheets as a practical three-step starter scale. Pair them with an 8 pt/dp small token for compact non-pill controls. These are project tokens, not platform mandates, so retain them only if they match the product’s intended sharp or soft brand signal.

Should iOS apps use continuous or circular corners?

iOS apps should use continuous corners for surfaces that follow the native iOS visual language. SwiftUI exposes this with RoundedRectangle using .continuous, while a standard rounded rectangle uses circular arcs. Android and cross-platform rendering often use circular corners, so check both curve types side by side before standardizing a shared component.

Why does a chip not need a radius scale token?

A full-pill chip does not need a radius scale token because its radius is always half of its final height. A 32 pt/dp chip has a 16 pt/dp radius, and a 40 pt/dp chip has a 20 pt/dp radius. This keeps the ends fully round when chip height changes for text, icon, or touch-target requirements.

Where this leaves you

A useful radius system is small enough to remember and strict enough to expose exceptions. Start with 8, 16, and 28 pt/dp for compact controls, cards, and sheets. Derive pills from height, and derive nested radii by subtracting edge padding from the outer radius. Then make the curve decision explicit: continuous for native-feeling iOS surfaces, circular where that is the chosen platform geometry. The next action is to build one chip-card-sheet reference screen and inspect its nested corners at device size before exporting implementation values.

---

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

---

Related

• •Flexbox Generator — Build a flex layout visually, then export it as CSS, Tailwind, SwiftUI, Compose, React Native or Flutter.
• •CSS Grid Generator — Lay out rows, columns and gaps visually, then export as CSS, Tailwind, LazyVGrid, Compose or Flutter.
• •Gradient Generator: Mobile UI Gradient Design — Use a gradient generator to design smooth mobile gradients, avoid 8-bit banding, protect t
• •Flexbox Generator: Mobile Layouts Without Queries — Use a flexbox generator or manual CSS to build a 320–440px mobile screen with stable heade
• •Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery

Sources

• •Apple Developer Documentation — RoundedRectangleStyle.continuous
• •Material Design 3 — Shape overview
• •Android Developers — Shapes in Compose