Why 100vh Doesn’t Always Fit a Mobile Screen

height: 100vh sounds like “fill the visible screen.” On a phone, browser controls appear and disappear, so there is more than one useful definition of the viewport height.

That mismatch can put a button below the visible area or make a full-screen panel jump while someone scrolls.

Mobile has several viewport heights

The traditional unit is one percent of the viewport height:

.hero { min-height: 100vh; }

Modern CSS adds three more explicit choices, documented in MDN’s length reference:

• svh uses the small viewport, with browser controls visible;
• lvh uses the large viewport, with controls retracted;
• dvh follows the dynamic viewport as controls change.

For a hero that must fit without hiding its bottom edge, I usually start with:

.hero { min-height: 100svh; }

For an app-like panel that should track the currently visible area:

.panel { height: 100dvh; }

Dynamic sizing can move during scrolling, so it is not automatically the calmest choice.

Prefer flexibility when exact height is unnecessary

min-height lets content grow:

.hero {
  min-height: 100svh;
  display: grid;
  place-items: center;
}

That is safer than forcing long text into exactly one screen. Full-height design should not make content overflow merely to preserve a mockup.

A fallback can come first:

.hero {
  min-height: 100vh;
  min-height: 100svh;
}

Browsers that understand svh use it; older ones keep vh. Width equivalents—svw, lvw, and dvw—exist too, though the mobile toolbar problem is usually about height.

100vh is not broken. It is simply one viewport definition. Choose the unit from the behaviour the component needs, and avoid an exact full-screen height when ordinary document flow would work better.

← Back to all articles