100vh on mobile: the toolbar problem, the new units and a better goal
On phones, 100vh is measured as if the browser's address bar and toolbar were hidden, so an element that tall runs off the bottom of the screen when the page first loads. Use svh when the whole element must be visible, dvh only when it must track the toolbar, and ask whether the element needs to fill the screen at all: usually it doesn't.
Why 100vh misbehaves
Mobile browsers show their address bar and toolbar when a page loads, then slide them away as you scroll down, and back as you scroll up. The visible area changes height every time. Browsers decided long ago that vh would not follow those changes, because resizing the page on every scroll caused text to jump. Instead, as the web.dev article on the large, small and dynamic viewport units explains, 100vh matches the height with the toolbars retracted. When they're showing, which is the state everyone sees first, a 100vh element is taller than the screen and its bottom edge, often holding the button, is hidden.
This is the "100vh mobile Safari" problem developers have searched for since the iPhone, but it isn't Safari-only. Chrome and other mobile browsers behave the same way.
The three new units
| Unit | Measured when | Stable? | Use it for |
|---|---|---|---|
svh (small) | Browser toolbars are showing | Yes | Anything that must be fully visible on first load |
lvh (large) | Browser toolbars are hidden | Yes | Backgrounds that should never show a gap; same as vh today |
dvh (dynamic) | Whatever the current state is | No, it changes while scrolling | Full-screen app shells, dialogs and overlays that must fit exactly |
MDN's length reference describes small viewport units as the safer general choice and warns that dynamic units can resize layout while people scroll, which hurts both smoothness and performance. The web.dev article adds that browsers throttle dynamic updates, so dvh can lag behind the toolbar. Each family also has width, inline, block, min and max versions, such as svw and dvmin.
Writing a full height hero for mobile
If you do want a tall hero, write it so it fits the first screen and never hides its own content:
- Use
min-height, notheight.min-height: 100svhlets the hero grow when the headline wraps onto four lines or the visitor enlarges text. A fixed height clips it. - Cap it. Something like
min-height: clamp(520px, 85svh, 900px)stops the hero becoming a sliver on a landscape phone or a cavern on a tall monitor. - Add a fallback. Put
min-height: 100vhon the line before thesvhrule for older browsers; the later line wins where it's supported. - Leave a hint of what's next. 85 to 90% of the small viewport lets the next section peek in, which tells people the page continues.
- Don't size text from height. Headlines in
vhunits shrink in landscape and break zoom.
Why forcing full height is rarely the goal
Full-screen heroes became a template default: a photo, a short headline and a button, then a scroll before anything useful. On a phone that first screen is precious. The visitor came for prices, a menu, opening hours or a booking form, and a hero that fills the screen pushes all of it below the fold for the sake of an atmosphere shot.
A hero sized to its content usually serves better: headline, one line of support, the main action and perhaps a key fact or two, then straight into the substance. The cases where a full-height opening earns its place are narrow: a photographer whose work is the message, an event with a single date and a single button, a product launch with one image. Even then, svh and a cap. For more on the opening section, see hero section design and video background websites.
Full-height heroes in Anticode
The Critic flags heroes forced to the full screen height: one of its nineteen checks is that the hero is sized to its content, and it flags a hero rule that sets 100vh. Most design-engine heroes are sized by their content and padding. The full-bleed photo hero is taller by design and uses min-height: clamp(560px, 84svh, 920px): its height follows the small viewport, measured with the toolbars showing, between a floor of 560px and a ceiling of 920px, which usually leaves a strip of the next section in view.
Questions people ask
Why is 100vh taller than my phone screen?
Because vh is measured with the browser toolbars hidden. On first load they're showing, so the element is taller than the visible area.
Should I use dvh or svh for a hero?
Usually svh. It's stable and fits with the toolbars showing. dvh changes while people scroll and can make the layout jump.
Is a full-height hero bad design?
Not always, but it's rarely necessary. On phones it often hides the content people came for.
Sources
- The large, small, and dynamic viewport units, web.dev, checked
- <length>, MDN Web Docs, checked