safe-area-inset-bottom Is 0 or Ignored? Fix an iPhone Footer

Use the smallest working pattern#

Opt into the full display area, then keep the base spacing separate from the device inset:

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

1
:root {
2
  --safe-area-bottom: env(safe-area-inset-bottom, 0px);
3
}
4

5
.mobile-footer {
6
  position: fixed;
7
  right: 0;
8
  bottom: 0;
9
  left: 0;
10
  padding: 0.75rem 1rem calc(0.75rem + var(--safe-area-bottom));
11
  background: Canvas;
12
}
13

14
main {
15
  padding-bottom: calc(4rem + var(--safe-area-bottom));
16
}

The footer’s padding moves its buttons above the home-indicator area while keeping the background edge-to-edge. The main padding prevents the last content from hiding behind the fixed footer. Adjust 4rem to the actual footer height; the safe-area inset is only the additional device spacing.

Why the inset is 0px#

env() reports the environment value for the current viewport. Common reasons for a zero value are:

The fallback in env(safe-area-inset-bottom, 0px) keeps the declaration valid when the environment variable is unavailable. It does not manufacture an inset on a device that reports none.

Measure the computed inset instead of guessing#

Reading a custom property’s source text can leave you looking at env(...) rather than the length used by a layout property. Put the environment value on a temporary probe and read its computed padding:

1
<div id="safe-area-probe" aria-hidden="true"></div>

1
#safe-area-probe {
2
  position: fixed;
3
  right: 0;
4
  bottom: 0;
5
  left: 0;
6
  padding-bottom: env(safe-area-inset-bottom, 0px);
7
  visibility: hidden;
8
  pointer-events: none;
9
}

1
const probe = document.querySelector('#safe-area-probe');
2
const viewport = document.querySelector('meta[name="viewport"]');
3

4
console.table({
5
  paddingBottom: getComputedStyle(probe).paddingBottom,
6
  viewport: viewport?.content ?? 'missing',
7
  displayMode: matchMedia('(display-mode: standalone)').matches
8
    ? 'standalone'
9
    : 'browser',
10
});

Run this on the device and display mode that shows the problem. Then use the result to choose the next check:

The safe-area inset describes the unsafe edge, not the entire footer and not every browser toolbar or software-keyboard transition. A positive inset can therefore be correct while a separate viewport or scrolling problem remains.

Put padding on the obscured box and the scroll container#

Two layout problems are often conflated:

1. The home indicator covers the footer’s buttons. Add the inset to the footer’s bottom padding.
2. The fixed footer covers the page’s last link or form field. Add enough bottom padding to the element that scrolls, such as main or the app’s scroll wrapper.

Changing only bottom: env(safe-area-inset-bottom) can move the whole footer upward and leave an unwanted gap below its background. Padding is usually the better first fix because it preserves the full-width surface while moving the controls.

If the page scrolls inside a nested element, padding on body may not affect the scrollable content. Apply the reservation to that nested scroll container and verify the final focusable element can scroll above the footer.

Check the viewport declaration and CSS box model#

Make sure there is one effective viewport declaration and that the page is allowed to use the display area. Then check:

• box-sizing and the footer’s actual rendered height after padding;
• whether another rule overrides the padding-bottom declaration;
• whether the fixed footer has a higher stacking order than content;
• whether a keyboard, browser toolbar, or dynamic viewport change is being mistaken for the safe-area inset;
• whether a sticky element has the same scroll container you are testing.

Do not use a hard-coded iPhone-only height. The safe-area variable is a runtime value, and the base padding should remain useful on devices that report 0px.

Test in the context that fails#

Desktop emulation can confirm that the declaration parses, but it cannot fully prove a home-indicator layout. Test the real target in a browser tab and, if relevant, as an installed home-screen web app. Scroll to the last interactive element, rotate the device, open the keyboard, and check that the footer background and controls behave independently.

Use the computed-padding probe above rather than inferring support from desktop emulation. If it reports 0px, test the target device and display mode before changing the formula. If it reports a positive value, move on to the footer box and scroll-container checks instead of adding a larger hard-coded inset.

FAQ#