Safe Area Inset: Notches and Dynamic Island

Safe area inset rules keep interactive mobile UI out of hardware and system-gesture regions: extend background imagery to the physical screen edges, then place every tappable control inside the reported top, bottom, leading and trailing insets. On iPhone 16 Pro models, reserve a 62pt top inset for the Dynamic Island and 34pt at the bottom for the home indicator; use the actual device inset for each target, not a single iPhone constant. On Android, test display cutout behaviour with the default, shortEdges and never modes before approving a full-bleed layout.

Key takeaways

• •Every Face ID iPhone in the supplied reference uses a 34pt bottom home-indicator inset.
• •iPhone 16 Pro and iPhone 16 Pro Max use a 62pt top safe area for the Dynamic Island.
• •iPhone 14 Plus uses a 47pt top safe area; iPhone 13 mini uses 50pt.
• •Web views need viewport-fit=cover before env(safe-area-inset-*) returns edge-to-edge safe-area values.
• •Android display cutout modes are default, shortEdges and never.

This guide is for mobile UI/UX designers, iOS and Android engineers, and product founders who already work with artboards, constraints or layout insets.

Time: 25 minutes · You'll need: Your screen design at its target device dimensions, An iPhone simulator or physical Face ID iPhone, Android Studio emulator or Android device with a display cutout, Browser device emulator for mobile web views, floow.design Notch & Safe Area Simulator (optional final check)

What's on this page

1. •Choose the target frames before placing controls
2. •Bleed backgrounds past safe area mobile design guides
3. •Test Dynamic Island design on contrasting screens
4. •Configure Android display cutout modes deliberately
5. •Apply CSS safe area inset values in web views
6. •Verify every persistent control with manual overlays
7. •Reference table

• •Common mistakes
• •FAQs

Setting safe area inset rules step by step

1. Choose the target frames before placing controls

Create at least one iOS and one Android frame at the exact reference dimensions. For an iOS Dynamic Island check, use iPhone 16 Pro: 402 × 874pt, with a 62pt top safe area and 34pt bottom safe area. For Android, use Pixel 9: 412 × 923pt, with a 48pt top and 24pt bottom inset.

Draw guides at each inset boundary. The upper guide marks the first valid y-position for a title, back button, close control or search field. The lower guide marks the last valid edge for a bottom sheet action, tab bar action, or persistent primary button. Treat these guides as content boundaries, not as the edge of the visual composition.

Do not make one generic “notched iPhone” frame. The supplied reference ranges from 47pt on iPhone 14 Plus to 62pt on iPhone 16 Pro models, and iPhone SE (3rd generation) has a 20pt top inset with no bottom home-indicator inset.

Tip: Keep a separate safe-area overlay component in the design file so it can be toggled on during review without becoming part of the shipped UI.

2. Bleed backgrounds past safe area mobile design guides

Extend solid colour, photos, maps, video, gradients and decorative artwork to all four physical screen edges. A full-bleed background can sit behind the Dynamic Island, status bar, camera cutout and home indicator because users do not need to tap or read it precisely there. This is the intended visual result: the screen feels continuous, while its functional content remains inset.

Keep controls, text that must be read, form fields, list-row actions and bottom-sheet buttons inside the safe area. A close button behind the Dynamic Island can be partially obscured; a purchase button over the home-indicator region competes with the system swipe gesture. The rule is not “leave the top blank.” A hero image may occupy the top 62pt on iPhone 16 Pro, but its title and actions must begin below that boundary.

Apply the same separation to Android punch-hole screens. Pixel 9 and Galaxy S24 frames in the reference each have a 48pt top inset, even though the visible camera opening is much smaller.

Tip: A dark status-bar region is not a reason to add a separate rectangular header background; let the screen background continue behind it unless readability testing shows a real failure.

3. Test Dynamic Island design on contrasting screens

Test the same screen on a Dynamic Island device, a notch device and an iPhone without either feature. Use iPhone 16 Pro Max (440 × 956pt) or iPhone 16 Pro (402 × 874pt) for the 62pt Dynamic Island case. Compare it with iPhone 14 Plus (428 × 926pt), which has a 47pt top inset and a notch, and iPhone SE (375 × 667pt), which has a 20pt top inset and no bottom inset.

Anchor top controls to the safe-area boundary, not to a hard-coded y-coordinate such as 62pt. This lets a navigation title, avatar, dismiss button or progress indicator move correctly when the device changes. The supplied device reference also shows that not every Dynamic Island phone has the same top figure: iPhone 16 / 15 is listed at 59pt. Use runtime safe-area values in production and use the device-specific frame values during design review.

Check the expanded Dynamic Island state separately when your app uses Live Activities or other system activity. Do not position an app control where an expanded system element can cover it.

Tip: The notch simulator check is most valuable on screens with a top-right action, because that is where visual centring often hides a collision.

4. Configure Android display cutout modes deliberately

Choose Android cutout behaviour per window rather than assuming every edge-to-edge screen should draw around a punch hole. Android exposes three named cutout modes: default, shortEdges and never. In default, Android applies the platform’s normal cutout handling. In shortEdges, the app may use the cutout area on the short edges of the display, which is commonly used by immersive media. In never, the app does not draw into a display cutout area.

Use shortEdges only when the content benefits from full-screen presentation, such as camera preview, video playback or a game canvas. Pair it with window inset handling so overlay controls remain clear of the punch hole and gesture area. Use never for screens where a stable rectangular content region matters more than edge-to-edge imagery, such as a dense form or a high-risk confirmation flow.

For standard product screens, keep a full-bleed background if desired and position app controls from Android’s reported window insets. Test on Pixel 9 and Galaxy S24 reference frames, both listed with 48pt top and 24pt bottom safe areas.

Tip: Do not use shortEdges to solve a spacing problem; it changes where the window may draw, not where your toolbar and buttons should be placed.

5. Apply CSS safe area inset values in web views

For an iOS or Android web view that must draw edge to edge, add this viewport declaration in the document head:

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

Then apply the browser-provided CSS environment variables to the functional layer, not necessarily to the page background:

.screen { min-height: 100dvh; }
.screen__content {
  padding-top: env(safe-area-inset-top);
  padding-right: env(safe-area-inset-right);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);
}

viewport-fit=cover permits the layout viewport to extend into the display’s unsafe regions. The env(safe-area-inset-*) values then provide the current inset values for content placement. Add your intentional spacing to them, such as calc(env(safe-area-inset-bottom) + 16px) for a bottom action, rather than replacing them with a fixed 34pt assumption. CSS pixels and iOS points are not interchangeable design tokens; validate the rendered result on the actual web-view device.

Tip: Put the safe-area padding on a content wrapper; padding the root background container often produces an unwanted blank band instead of a true full-bleed surface.

6. Verify every persistent control with manual overlays

Perform a manual review before handoff. On each target frame, overlay the device’s top and bottom safe-area guides and inspect every persistent interactive element: navigation actions, close buttons, segmented controls, floating buttons, bottom tabs, composer fields and checkout actions. Nothing tappable should cross a guide. Background layers should cross both guides and reach the physical frame edge.

Review at least these supplied reference cases: iPhone 16 Pro at 62pt / 34pt, iPhone 14 Plus at 47pt / 34pt, iPhone SE at 20pt / 0pt, and Pixel 9 at 48pt / 24pt. This catches the common failure where a layout works on a home-button iPhone but puts a bottom action under the Face ID home indicator.

As a final optional check, preview the completed screen in floow.design’s free Notch & Safe Area Simulator at /free-tools/notch-safe-area-simulator. The manual overlay remains the source of the design decision; the simulator is a fast cross-device verification and code-export check.

Tip: Review a bottom sheet in its partially expanded state as well as its fully expanded state; its primary action is often positioned differently in the two states.

Reference table

Reference safe areas by target device

Do it with the free Notch & Safe Area Simulator

Preview your screen against real notches and home indicators, and export the inset code for six platforms.

Open the Notch & Safe Area Simulator → — free, no sign-up.

Common mistakes

Using a 34pt bottom margin on every iPhone.

Use the runtime bottom safe-area inset. iPhone SE (3rd generation) is listed with a 0pt bottom inset, while the supplied Face ID iPhones use 34pt.

Stopping a background at the top safe-area guide.

Bleed decorative and non-interactive backgrounds to the physical edge. Inset the title, controls and readable content layer instead.

Hard-coding 62pt for every top cutout.

Use a device-specific design frame and platform-reported insets in code. The reference lists 47pt on iPhone 14 Plus, 50pt on iPhone 13 mini and 59pt on iPhone 16 / 15.

Using Android shortEdges without inset-aware overlay controls.

shortEdges` permits drawing into a short-edge cutout area; it does not move controls away from the cutout or gesture navigation area.

Frequently asked questions

What is the safe area inset on an iPhone with Dynamic Island?

iPhone 16 Pro and iPhone 16 Pro Max use a 62pt top safe-area inset and a 34pt bottom inset in the supplied device reference. Do not turn that into a universal Dynamic Island constant: iPhone 16 / 15 is listed at 59pt. Production layouts should read the platform’s current safe-area values.

Do I need a notch simulator to test a mobile screen?

A notch simulator is useful for visual verification, but you can test manually by overlaying each target device’s top and bottom safe-area guides on the artboard. Check at least one Dynamic Island, notch, no-cutout iPhone and Android punch-hole frame. Test every persistent control, not only the header.

Should backgrounds respect the safe area on mobile?

Backgrounds should extend past the safe area to the physical display edge, while controls and essential text should remain inside the safe area. A background behind a cutout has no tap target or readability requirement. A close button, payment action or bottom tab behind a system region can be obscured or hard to operate.

How do I use env(safe-area-inset-bottom) in CSS?

Use env(safe-area-inset-bottom) as padding on the content layer after adding viewport-fit=cover to the viewport meta tag. For a fixed bottom action, use a calculation such as calc(env(safe-area-inset-bottom) + 16px) so the intended 16px spacing remains above the system inset. Keep the background outside that padded wrapper.

Which Android display cutout mode should I use?

Use Android’s default mode for ordinary app screens, shortEdges for deliberate immersive edge-to-edge content, and never when the app must avoid cutout areas. Whichever mode you choose, position controls from window insets. The cutout mode controls drawing permission; it does not replace inset-aware layout.

Where this leaves you

A full-bleed mobile screen has two layers with different jobs. The visual layer reaches every physical edge, including behind the Dynamic Island, notch, punch hole and home indicator. The functional layer begins after the current platform insets, so a user can see and tap every control without competing with system UI or gestures. Do not approve a screen from one iPhone artboard alone: iPhone 16 Pro, iPhone 14 Plus, iPhone SE and a Pixel 9 expose four meaningfully different edge conditions. Your next action is to add visible safe-area guides to the current screen and move every persistent control inside them.

---

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

• •Aspect Ratio Calculator — Work out the missing width or height for any ratio, with the common phone and store ratios one click away.
• •Device Size Reference — Screen dimensions, density and safe areas for current handsets — searchable, and exportable as code.
• •Aspect Ratio Calculator for Mobile App Screens — Use an aspect ratio calculator to size mobile heroes, cards and thumbnails, preserve safe
• •px to rem Converter: Convert px to dp and pt — Use a px to rem converter method to translate mobile spacing into Android dp, iOS pt and w
• •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 Human Interface Guidelines — Layout
• •Apple Safari Web Content Guide — Configuring the Viewport
• •Android Developers — Display cutout support
• •Android Developers — Edge-to-edge views
• •W3C CSS Environment Variables Module Level 1