A safe area is the part of a mobile screen where content is guaranteed to be visible and interactive, because it is not covered by hardware cutouts, rounded display corners, system bars or the home gesture indicator. In mobile UX, the safe area is expressed as a set of insets, distances from each screen edge that layouts must respect.
Modern phones use edge-to-edge displays, so the physical screen and the usable screen are no longer the same rectangle. Respecting the safe area lets an app draw backgrounds to the very edges while keeping text, buttons and controls away from obstructions.
What defines the safe area on a phone
The operating system calculates safe area insets at runtime from the device model, orientation and current system interface. The insets change when the device rotates, when the status bar hides, when an on-screen keyboard appears, or when the app runs in a split or windowed mode.
The table lists the elements that most often reduce the safe area and where they appear.
| Obstruction | Typical location | Affects |
|---|---|---|
| Notch or camera cutout | Top edge, or side in landscape | Headers, titles, toolbars |
| Rounded corners | All four corners | Corner buttons and badges |
| Status bar | Top edge | Top navigation content |
| Home gesture indicator | Bottom edge | Bottom navigation and buttons |
| Navigation bar | Bottom or side on Android | Bottom content and floating buttons |
| On-screen keyboard | Bottom when visible | Input fields and submit buttons |
The values vary by model. On a recent full-screen iPhone in portrait, the top inset is roughly 45 to 60 points and the bottom inset is about 34 points, while older devices with a home button have a much smaller top inset and no bottom inset. Hard-coding any of these numbers is a common source of broken layouts.
How platforms expose safe area insets
Each platform provides an inset API that reports the values so a layout can adapt automatically. Developers should read these values instead of guessing them from the screen size.
| Platform | Mechanism | Typical use |
|---|---|---|
| iOS UIKit | safeAreaLayoutGuide, safeAreaInsets | Constrain views to the guide |
| iOS SwiftUI | Automatic safe area, ignoresSafeArea | Extend backgrounds only |
| Android | WindowInsets, display cutout API | Apply padding from system bar insets |
| Jetpack Compose | WindowInsets modifiers | safeDrawing or systemBars padding |
| Flutter | SafeArea widget, MediaQuery padding | Wrap screens or read padding |
| Mobile web | env(safe-area-inset-*) in CSS | Requires viewport-fit=cover |
Android has moved toward mandatory edge-to-edge drawing for apps that target recent API levels, so Android apps can no longer rely on the system to keep content out from under the status and navigation bars. They must apply insets explicitly, just as iOS apps do.
On the mobile web, a page only receives non-zero values from the env(safe-area-inset-top) family when the viewport meta tag includes viewport-fit=cover. Without it, the browser letterboxes the page and the insets stay at zero.
Safe area compared with related layout concepts
The safe area is often confused with layout margins and with the viewport. They answer different questions, and good layouts use all three together.
| Concept | Question it answers | Set by |
|---|---|---|
| Safe area | Where is content not obstructed | Operating system, at runtime |
| Layout margins | How far content sits from edges for readability | Design system |
| Viewport | What area the app or page draws into | Window or browser |
| Gesture zones | Where swipes trigger system actions | Operating system |
| Adaptive layout | How structure changes with available space | App design |
A practical rule is to add design margins on top of the safe area insets, not instead of them. Gesture navigation adds a further constraint: even inside the safe area, controls placed very close to the left, right or bottom edge may conflict with system back and home gestures.
Designing layouts that respect the safe area
The usual pattern is to let backgrounds, images and scroll content extend under the system bars for an immersive look, while keeping interactive and readable elements inside the safe area.
- Extend backgrounds edge to edge, including behind the status bar and home indicator.
- Pad bottom navigation by the bottom inset so tabs sit above the home indicator.
- Let scroll views scroll under bars, but inset their content so the first and last items are reachable.
- Handle landscape, where the cutout and rounded corners move to the sides.
- React to keyboard insets so active fields and buttons stay visible while typing.
Full-screen media, such as video players and camera views, may intentionally ignore the safe area for the image itself, but overlay controls like close buttons and timelines should still respect it.
Common safe area mistakes
Safe area defects usually appear only on specific devices or orientations, so they escape testing on a single phone. The table shows the most frequent cases.
| Symptom | Cause | Fix |
|---|---|---|
| Title hidden behind the notch | Header pinned to the screen top | Constrain to the top safe area inset |
| Tab bar overlaps home indicator | Fixed height without bottom inset | Add the bottom inset to the bar height |
| Blank band at the top | Whole screen inset, background too | Extend only the background to the edge |
| Clipped side buttons in landscape | Insets read only once at launch | Update layout on inset changes |
| Zero insets on mobile web | Missing viewport-fit=cover | Add it and use env() padding |
Testing on at least one device with a cutout, one with gesture navigation and one older model, in both orientations, catches most of these issues before release.
Stripped to the essentials
Modern phone screens are not perfect rectangles. They have rounded corners, a camera cutout at the top and a small bar at the bottom for swiping home.
The safe area is the part of the screen where nothing gets in the way. Think of a framed picture: the picture may run under the edge of the frame, but anyone hanging it makes sure the important part stays visible inside the frame. Apps do the same with their text and buttons.
Where it is applied
A food delivery app receives complaints that its checkout button is hard to tap on newer phones. Investigation shows the button is pinned to the bottom of the screen with a fixed height of 56 points, so the home gesture indicator sits on top of it, and some taps trigger the system home gesture instead of the order.
The team moves the button above the bottom safe area inset, keeps the button background extending to the bottom edge, and adds keyboard inset handling so the button stays visible while customers type a delivery note. They also fix the order tracking header, which was partly hidden behind the camera cutout in landscape.
After release, accidental home gestures on the checkout screen disappear from user feedback, and the completed order rate on newer devices returns to the level seen on older phones.