layout · platform-registers
Safe area
also called safe area inset (community), safe area layout guide (hig), safe zone (community), env(safe-area-inset-bottom) (css), window insets (android)
The part of the screen guaranteed clear of notches, system bars and rounded corners, where interactive content can safely sit.
A screen and a usable screen stopped being the same rectangle in 2017, when the iPhone X put a camera housing into the top of the display and a gesture bar across the bottom. The safe area is what is left: the part of the viewport where you can put a button and know it will be neither covered by system furniture nor cut off by a rounded corner. Everything outside it is still yours to paint, which is the point of going edge to edge, but it is not yours to put a control in.
On the web the safe area arrives as four environment variables,
env(safe-area-inset-top | right | bottom | left), usable anywhere a length is: as padding on
a fixed bar, inside a calc(), or as a max(16px, env(safe-area-inset-bottom)) so a phone
with no notch still gets ordinary spacing. They resolve to zero until the page opts out of the
browser’s own letterboxing with viewport-fit=cover in the viewport meta tag, which is the
single most common reason a correct-looking rule appears to do nothing. The values are live:
they change on rotation, and Safari also feeds the keyboard and toolbars into
env(keyboard-inset-*) and the visual viewport rather than into these.
Every platform has the same idea under a different name. UIKit gives a view a
safeAreaLayoutGuide and a safeAreaInsets rectangle to constrain against, SwiftUI applies
it by default and makes you say ignoresSafeArea to leave it, and Android calls the whole
family window insets: system bars, display cutouts, gesture navigation, and the IME each
report their own, which is why the Android advice is to consume the specific inset you care
about rather than the union of all of them. Android 15 made edge-to-edge the default for apps
targeting it, which converted a stylistic choice into a correctness requirement in the same
way viewport-fit=cover does on the web.
The failures are boringly repeatable and worth recognising by shape. A
sticky footer or a bottom navigation bar with a plain
padding-bottom sits its tap targets under the home indicator, where the operating system
will happily eat the touch. A full-bleed hero with a title at the very top puts that title
behind the clock. A landscape layout forgets that the notch becomes a left or right inset, not
just a top one. The habit that avoids all of it: let backgrounds run to the physical edge and
let content stop at the safe one.
Which word?
| If you want | say |
|---|---|
| the region a control can occupy without being clipped | safe area |
| naming the hole the layout must dodge | display cutout |
| the reserved strip at the bottom of a modern phone | home indicator |
| content under the bars, controls kept clear of them | edge to edge |
Related
See also: Focus not obscured · Layout margins · Status bar
Implementations
Specimens illustrate the concept; for production use, start here.
| hig | safeAreaLayoutGuide |