Viewport Units Explained: svh, lvh, dvh, and Why They Matter

You've likely encountered this: a hero section or full-screen overlay set to `height: 100vh` that gets clipped on mobile — the bottom is hidden behind the browser's address bar or navigation controls.

This happens because mobile browsers have *dynamic* chrome. The address bar appears when you load a page and shrinks (or disappears) as you scroll down. Early `vh` was defined against the *largest* possible viewport (with chrome hidden). This caused `100vh` to be taller than the visible area when chrome is visible, triggering overflow and layout shifts.

The CSS Working Group solved this by introducing three distinct viewport size variations in 2022.

/* Small viewport — assume chrome is fully visible (max chrome) */
.section { height: 100svh; }

/* Large viewport — assume chrome is hidden (min chrome) */
.section { height: 100lvh; }

/* Dynamic viewport — tracks the actual current chrome state */
.section { height: 100dvh; }

• svh (Small Viewport Height): Based on the smallest possible viewport — when all browser chrome (address bar, navigation, toolbars) is fully visible. This is the 'safe' unit — content sized with `svh` is always fully visible.

• lvh (Large Viewport Height): Based on the largest possible viewport — when all chrome is hidden (after scrolling). Content sized with `lvh` might initially be clipped, but fills the screen when chrome retracts.

• dvh (Dynamic Viewport Height): Tracks the actual viewport size in real time as chrome appears and disappears. This eliminates the gap but causes layout reflow as the user scrolls — use with caution for animated content.

The right choice depends on your use case:

For full-screen hero sections:

.hero {
  min-height: 100svh; /* Always fully visible, never clipped */
}

For modals and overlays:

.overlay {
  height: 100dvh; /* Match whatever the current visible area is */
}

For sticky sidebars:

.sidebar {
  height: 100svh; /* Stable, no layout reflow */
  overflow-y: auto;
}

The general recommendation: Default to `svh` for static layouts. Use `dvh` only when you need pixel-perfect visible-area coverage and the element isn't animated.

The spec introduced these across all dimensions:

/* Height variants */
height: 100svh; /* small */
height: 100lvh; /* large */
height: 100dvh; /* dynamic */

/* Width variants */
width: 100svw;
width: 100lvw;
width: 100dvw;

/* Inline/Block (logical) */
inline-size: 100svi;
inline-size: 100lvi;
inline-size: 100dvi;

block-size: 100svb;
block-size: 100lvb;
block-size: 100dvb;

/* Min and Max shorthand */
inline-size: 100svmin;
inline-size: 100svmax;

These units reached Baseline Widely Available in 2023.

• Chrome 108+ ✅ • Firefox 101+ ✅ • Safari 15.4+ ✅ • Edge 108+ ✅

Safe to use in production today without any fallbacks for modern browser targets.

1. Using `dvh` for everything `dvh` causes layout reflow on scroll because the value changes as browser chrome shows/hides. This can trigger paint events and jank in complex layouts. Use `svh` for static elements.

2. Forgetting the old `vh` in the fallback For browsers that don't support the new units, `vh` remains a valid fallback:

.hero {
  min-height: 100vh; /* fallback */
  min-height: 100svh; /* modern browsers */
}

3. Assuming `dvh` is always 'correct' `dvh` reflects the current viewport size — which might be smaller than expected when the keyboard is open on mobile. Test on real devices.

What about vb and vi units? `vb` (viewport block size) and `vi` (viewport inline size) are logical equivalents to `vh` and `vw` for vertical writing modes. They also have s/l/d variants.

Is `100dvh` the same as `100%` height? No. `100%` height requires the parent to have a defined height. `100dvh` is absolute — it's the dynamic viewport height regardless of parent context.

Do these units affect Desktop? On desktop, browser chrome is typically static (or absent). `svh`, `lvh`, and `dvh` all resolve to the same value on desktop — so these units are primarily a mobile concern.