Why is my env(safe-area-inset-*) padding doing nothing?

Almost always because the page is missing viewport-fit=cover in its viewport meta tag. By default the browser keeps your layout inside the safe area and reports every env(safe-area-inset-*) value as 0, so padding by those values changes nothing. Add the viewport meta tag with viewport-fit=cover (the tool generates this for you) so the layout draws edge-to-edge and the insets become non-zero. The audit in this tool warns you whenever the reminder is off.

Why wrap the inset in max() instead of using env() directly?

On a device with no inset on a given side - an older phone, a desktop, or simply the left/right edges in portrait - env() resolves to 0. A bare padding: env(safe-area-inset-bottom) then collapses to nothing, leaving content flush against the screen edge. max(16px, env(safe-area-inset-bottom)) keeps a sensible baseline padding everywhere and only grows it where the hardware actually reserves space. That is why max-combined is the recommended default output here.

Do the inset values change between portrait and landscape?

Yes, significantly. In portrait the notch or Dynamic Island sits at the top (so the top inset is large) and the home indicator at the bottom. Rotate to landscape and the cutout moves to one side, so the large insets shift to left and right while the top inset usually drops to 0 and the bottom home-indicator inset shrinks. The preview and stat cards in this tool reflect the orientation you select, which is why padding both left and right matters for landscape layouts.

How do I add safe-area padding in Tailwind CSS?

Tailwind ships no safe-area utilities in core, so you have two options. For a one-off, use an arbitrary value: pb-[env(safe-area-inset-bottom)] on a bottom nav, or the sturdier pb-[max(1rem,env(safe-area-inset-bottom))] to keep a baseline on devices with no inset. For anything you use more than once, register proper utilities — .pb-safe, .pt-safe, and friends — which is exactly what this tool exports: a tailwind.config.js plugin for v3 or an @theme/@utility CSS snippet for v4. Either way, none of it does anything until your viewport meta tag includes viewport-fit=cover.

What is the difference between the Tailwind v3 and v4 output?

Tailwind v3 configures utilities through JavaScript: the output is a tailwind.config.js plugin that calls addUtilities to register .p-safe, .pt-safe, and so on. Tailwind v4 moved configuration into CSS, so the v4 output is an app.css snippet using @theme to expose the insets as --spacing-safe-* tokens plus @utility blocks for the padding classes. Pick the one that matches your Tailwind major version; both produce the same effective max(Npx, env(...)) padding.

Are the device inset values exact?

They are realistic CSS-pixel approximations, not raw device pixels, and they are accurate enough to design against. The values differ slightly by OS version and are not something Apple or Google publish as a stable contract - which is exactly why you should always read them at runtime via env() rather than hard-coding numbers. Treat the catalogue as a reliable preview and reference; ship the env()-based CSS so the real device fills in its own values.

Which sides should I usually pad?

It depends on what the element is. A full-screen container generally pads all four sides. A bottom navigation bar or tab bar pads the bottom (and the sides in landscape). A sticky header or status bar pads the top. A floating action button offsets its bottom and trailing edge. The presets cover these common cases, and the recipes output gives you copy-paste rules for a bottom nav, a header, and a FAB that already combine env() with your baseline padding.

Safe Area Inset Calculator

Pick a device and orientation, choose which sides to pad, and copy the exact env(safe-area-inset-*) CSS — as plain classes, an @supports-guarded block, the max(Npx, env(...)) pattern, a Tailwind v3 plugin, a Tailwind v4 @theme snippet, or ready-made recipes for a bottom nav bar, sticky header, and floating action button. A live device preview shows the unsafe regions in red and the safe content area in green.

About this ToolHow it works, benefits & use cases

A focused generator for the env(safe-area-inset-*) CSS that keeps your content clear of notches, the Dynamic Island, punch-hole cameras, rounded corners, and gesture-nav home indicators. Pick a device from an expanded catalogue (iPhone 15/16 Dynamic Island lines, the classic notch phones, iPhone SE, iPad Pro, plus Android examples like the Pixel 8 and Galaxy S24), switch between portrait and landscape, and choose exactly which sides to pad. A live device-frame preview overlays the unsafe regions in red and the resulting safe content area in green, and inset stat cards plus a usable-viewport summary show how much screen the hardware reserves. Then export the exact recipe you need: plain .safe-* classes, an @supports-guarded block, the recommended max(Npx, env(...)) pattern that keeps a baseline padding everywhere, a Tailwind v3 plugin, a Tailwind v4 @theme/@utility snippet, or three real-world recipes for a fixed bottom navigation bar, a sticky header, and a floating action button. A built-in audit catches the silent failure mode: without viewport-fit=cover in your viewport meta tag, every inset resolves to 0 and the padding does nothing.

How to Use

1Start from a preset - Full-screen app, Bottom tab bar, Notch-safe header, or Landscape side insets - or configure by hand.
2Pick the device and toggle portrait / landscape; the preview and inset cards update to match the hardware insets.
3Choose which sides to pad (top / right / bottom / left). For landscape notches the cutout moves to the left and right.
4Set a minimum padding to combine via max(), then pick an output format: max-combined is the recommended default.
5Keep the viewport-fit=cover reminder on, add that meta tag to your <head>, and copy the generated CSS or share the URL.

Key Benefits

Expanded device catalogue: Dynamic Island, classic notch, iPhone SE, iPad Pro, and Android (Pixel 8, Galaxy S24)
Live device-frame preview showing unsafe regions in red and the safe content area in green, per orientation
Six output formats including the recommended max(Npx, env(...)) pattern, a Tailwind v3 plugin, and a Tailwind v4 @theme snippet
Ready-made recipes for a fixed bottom nav bar, a sticky header, and a floating action button
Inset stat cards and a usable-viewport summary (px and percentage) for both width and height
Audit that flags the missing viewport-fit=cover tag, which would silently zero out every inset
Everything captured in a shareable URL so you can hand a teammate the exact configuration

Common Use Cases

Padding a fixed bottom tab bar so it clears the home indicator on a notched iPhone
Building a sticky header that stays below the Dynamic Island or notch
Setting up an edge-to-edge installed PWA with viewport-fit=cover and the matching safe-area padding
Adding Tailwind safe-area utilities (v3 plugin or v4 @theme) to a mobile-first design system
Checking how much usable screen a given device and orientation actually leaves for content

Device preview

iPhone 16 Pro / 16 Pro Max

Safe area

59px

Top

0px

Right

34px

Bottom

0px

Left

Usable viewport (portrait, 393×852)

Height: 759px (89.1%)Width: 393px (100.0%)

Safe-area CSS

max(Npx, env(...)) — recommended

.safe-area {
  padding-top: max(16px, env(safe-area-inset-top));
  padding-bottom: max(16px, env(safe-area-inset-bottom));
}

Required meta tag

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

Without viewport-fit=cover every env(safe-area-inset-*) returns 0 and the padding does nothing.

Looks good

Presets

Custom configuration — adjust any option below.

Options

Device

Dynamic Island. Top inset 59px portrait, home-indicator 34px.

Orientation

Apply to sides

Top

Right

Bottom

Left

Minimum padding (combined via max())

Output format

Show viewport-fit=cover reminder

env(safe-area-inset-*) only resolves to a non-zero value when this meta tag is present.

What are safe-area insets?

Phones with a notch, Dynamic Island, punch-hole camera, rounded corners, or a gesture-nav home indicator reserve part of the screen. When your layout draws edge-to-edge with viewport-fit=cover, the browser exposes the reserved sizes through the env(safe-area-inset-top/right/bottom/left) CSS variables so you can pad content out of the way.

Why the max() pattern

On a device with no inset, env() is 0, so a bare padding-bottom: env(safe-area-inset-bottom) collapses to nothing. Wrapping it in max(16px, env(safe-area-inset-bottom)) keeps a sensible baseline padding everywhere and grows it only where the hardware needs more — which is why it is the recommended default here.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Safe Area Inset Calculator

How to Use

Key Benefits

Common Use Cases

Device preview

Presets

Options

What are safe-area insets?

Why the max() pattern

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Safe Area Calculator