# Tailwind Safe Area Insets: Bottom Bars, FABs and Toasts
> A Tailwind safe area guide for v4: opt in with viewport-fit=cover, pad bars with env(safe-area-inset-bottom) and keep FABs and toasts off the home indicator.
- Author: [Serban Rusu](https://wingo-ui.com/blog/authors/serban), Founder of Wingo UI
- Published: Oct 9, 2026
- Category: [Mobile UI in React](https://wingo-ui.com/blog/category/mobile-ui)
- Reading time: 12 min
- Canonical: https://wingo-ui.com/blog/tailwind-safe-area-insets
## TL;DR
Tailwind CSS v4 has no safe area utilities, so you set viewport-fit=cover and pad every element pinned to a screen edge with env(safe-area-inset-*), either as arbitrary values like pb-[max(env(safe-area-inset-bottom),12px)] or as a few @utility classes. Keep bottom bars at bottom-0 and pad them on the inside, so their background runs under the home indicator. Place a floating button at the larger of the bar height and the inset, plus a gap, and let a second bar pad only the part of the inset the first one leaves uncovered, so the gap is never doubled.
You let the page fill the screen with `viewport-fit=cover`, pin a tab bar to `bottom-0`, open it on an iPhone, and the home indicator sits on top of your labels. Turn the phone sideways and the notch clips the start of every row. In Tailwind CSS v4, Tailwind safe area handling is up to you, because core ships no classes for it: everything pinned to an edge has to pad itself with `env(safe-area-inset-*)`. This tutorial builds the bottom of a phone screen, with a tab bar, a buy bar, a floating action button and toasts, so that none of them hides under the notch or the home indicator and none of them doubles the gap when they stack.
Safe areas are one of the nine rules in [Mobile-first React components](https://wingo-ui.com/blog/mobile-first-react-components). This post is the step by step version, with the arithmetic for bars that sit on top of each other.
## What does viewport-fit cover change?
It tells the browser that your page handles the screen's cutouts itself. With the default, `viewport-fit=auto`, Safari on an iPhone insets the page so nothing lands under the notch or the rounded corners, and fills the leftover strips with the background color of `` or `` ([WebKit, 2017](https://webkit.org/blog/7929/designing-websites-for-iphone-x/)). With `cover`, the viewport fills the whole display, and [MDN's viewport reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport) says it is "highly recommended" to use the safe area inset variables so that important content stays visible.
Android joined in 2025. From [Chrome 135](https://developer.chrome.com/docs/css-ui/edge-to-edge), Chrome on Android phones draws edge to edge. By default it shows a "chin" over the gesture bar that slides away as you scroll, and a `position: fixed; bottom: 0` bar ends up behind the navigation bar once the chin is gone. A page that sets `viewport-fit=cover` goes edge to edge on load and never shows the chin. Either way, the insets now matter on Android too.
In the Next.js App Router the meta tag comes from a `viewport` export in the root layout, which has to be a Server Component:
```tsx
// app/layout.tsx
import type { Viewport } from "next";
export const viewport: Viewport = {
width: "device-width",
initialScale: 1,
viewportFit: "cover",
};
```
Next.js renders it as ``. Outside Next.js, write that tag yourself. Treat `cover` as a promise: from now on, every element you pin to an edge pads itself.
## Why does env safe-area-inset-bottom return 0?
Usually because the page has no `viewport-fit=cover`, or because nothing covers that edge on the device you are testing. Without `cover`, Safari keeps the page inside the safe area itself, so on an iPhone there is no inset left to report. Desktop browsers report 0 as well ([MDN on env()](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/env)), so a layout that looks right in a narrow desktop window proves nothing. An iPhone with a Home button, like the iPhone SE, has no home indicator and reports 0 at the bottom, which is why every rule below pairs the inset with a minimum instead of trusting it alone.
Check the rendered page, not your source: open the head in the inspector and make sure there is exactly one viewport tag and that it carries `viewport-fit=cover`. A second tag added by a plugin or a hand-written `` can override the first. Variable names are case-sensitive too, so `env(SAFE-AREA-INSET-BOTTOM)` silently falls back.
## How do you write a Tailwind safe area inset bottom utility?
Use an arbitrary value for a one-off, and define a few `@utility` classes once it shows up in more than two places. Tailwind CSS v4 has no safe area utilities in core: as of version 4.3.3, the only `-safe` classes are alignment ones like `justify-center-safe`, which map to the CSS `safe` overflow keyword and have nothing to do with the notch.
The arbitrary value works anywhere: `pb-[max(env(safe-area-inset-bottom),12px)]`. For a project, put a small set in your stylesheet:
```css
/* app/globals.css */
@import "tailwindcss";
@utility pt-safe {
padding-top: env(safe-area-inset-top, 0px);
}
@utility pb-safe {
padding-bottom: env(safe-area-inset-bottom, 0px);
}
/* the inset, but never less than a spacing step: pb-safe-or-3 */
@utility pb-safe-or-* {
padding-bottom: max(env(safe-area-inset-bottom, 0px), --spacing(--value(integer)));
}
/* landscape: the notch side gets the inset, the other side keeps the gutter: px-safe-or-4 */
@utility px-safe-or-* {
padding-left: max(env(safe-area-inset-left, 0px), --spacing(--value(integer)));
padding-right: max(env(safe-area-inset-right, 0px), --spacing(--value(integer)));
}
/* a gap on top of the inset, for floating elements: bottom-safe-offset-4 */
@utility bottom-safe-offset-* {
bottom: calc(env(safe-area-inset-bottom, 0px) + --spacing(--value(integer)));
}
```
The `-*` at the end of a name makes a utility functional, and `--value(integer)` reads the number after it, so `pb-safe-or-3` compiles to `padding-bottom: max(env(safe-area-inset-bottom, 0px), calc(var(--spacing) * 3))`, and variants like `md:pb-safe` work as they do for any other class. If you would rather install the whole set (margins, scroll padding, `h-dvh-safe`, and `-offset-` and `-or-` forms for each), the [tailwindcss-safe-area](https://www.npmjs.com/package/tailwindcss-safe-area) package adds it with `@import "tailwindcss-safe-area";` (version 1.3.0, MIT license, as of October 2026).
The two functions do different jobs. Use `max()` when the inset replaces your normal spacing, like a bar's bottom padding or a toast's gutter: on a phone with a home indicator the inset wins, and on a laptop your 12px does. Use `calc()` when you need a gap on top of the inset, like a button that floats 16px above the indicator. WebKit's original post uses the `max()` form for side padding for the same reason.
## How do you pad a fixed bottom bar?
Pad the inside of the bar and leave the bar itself at `bottom-0`. Its background then runs under the home indicator, and the padding lifts the tappable row above it. The iPhone home indicator CSS fix is one class on the bar, `pb-safe`:
```tsx
// components/tab-bar.tsx
import Link from "next/link";
import { House, Search, ShoppingBag, UserRound } from "lucide-react";
const tabs = [
{ href: "/", label: "Home", icon: House },
{ href: "/search", label: "Search", icon: Search },
{ href: "/cart", label: "Cart", icon: ShoppingBag },
{ href: "/account", label: "Account", icon: UserRound },
];
export function TabBar() {
return (
);
}
```
The row stays 64px tall everywhere. On a phone with a home indicator the bar grows by the inset; on a desktop the inset is 0 and nothing changes. `px-safe-or-2` keeps the first and last tab clear of the notch in landscape. Each tab is a quarter of the screen wide and 64px tall, comfortably above the [minimum touch target size](https://wingo-ui.com/blog/minimum-touch-target-size-react-tailwind).
Moving the bar up with `bottom-[env(safe-area-inset-bottom)]` looks similar in a screenshot, but the page then scrolls through a visible strip under the bar. Chrome's guide shows the same effect on Android.
The content behind the bar needs the same space, or the last row of a list never scrolls into view:
```tsx
{children}
```
### What about Chrome's warning against padding with the inset?
It applies to pages that keep the chin. Chrome's guide says not to set `padding-bottom` to `env(safe-area-inset-bottom)`, because without `cover` the inset changes while the chin slides away, the padding forces a layout on every step, and Chrome stops sliding the chin away when it detects that pattern. With `viewport-fit=cover` there is no chin to slide.
If you cannot opt in, use Chrome's alternative: reserve the largest inset up front and move the bar with `bottom`, a `calc(env(safe-area-inset-bottom, ...) - ...)` pattern that Chrome has a fast path for. Tailwind's preflight sets `box-sizing: border-box`, so the height has to include the padding:
```tsx
```
`safe-area-max-inset-bottom` arrived in Chrome 135. The 36px fallback is the value Chrome's guide uses for browsers without it.
## How do you stack a FAB above a tab bar without doubling the gap?
Put the bar's full height, inset included, in a CSS variable, then place the button at the larger of that variable and the inset, plus your gap. Adding them double-counts: the bar's height already contains the inset, so `bar + inset + 16px` floats the button a whole home indicator strip too high.
For the static bar above, the variable can be pure CSS. Set it on a wrapper so the button inherits it, and reset it where the bar is hidden:
```tsx
// components/mobile-shell.tsx
import type { ReactNode } from "react";
import { Plus } from "lucide-react";
import { TabBar } from "@/components/tab-bar";
export function MobileShell({ children }: { children: ReactNode }) {
return (