Viewport units: vw, dvh, svh and lvh

Viewport units size things as a share of the browser’s viewportviewport: A viewing or layout reference area used by the browser; a viewport-based length names which size and direction supply its reference.: vw is 1 % of its width and vh 1 % of its height, so 100vh is one full screen. Phones complicate the height, because their browsers show toolbars when a page opens and hide them while the reader scrolls. CSS therefore has three viewport heights. svh measures the small viewportsmall viewport: The viewport-size reference associated with the browser's retractable interface being expanded., with the toolbars shown. lvh measures the large viewportlarge viewport: The viewport-size reference associated with the browser's retractable interface being retracted., with them hidden. dvh measures the dynamic viewportdynamic viewport: A viewport-size reference that follows the browser's current retractable-interface state., whichever of the two is on screen right now. Plain vh is the large one, so a 100vh section can sit partly behind the toolbars. Use svh for full-screen sections, dvh for app shells that must match the visible area, and 100% rather than 100vw for full widths, because vw includes a desktop scrollbar. The supplied comparison cases below use Chromium 153, Firefox 155 and WebKit 26.6.

Viewport heights follow one of three toolbar states

The viewport is the part of the window that shows the page. On a desktop its height changes only when the window does. On a phone the browser’s address bar and buttons slide away as the reader scrolls down, so the space for the page grows, and they come back on scrolling up. CSS Values 4 names the two extremes and the moving value between them:

• svh (small) assumes every retractable toolbar is shown: content this tall always fits, with a gap below once the toolbars hide.
• lvh (large) assumes they are all hidden: content this tall fills the screen once they hide, but the toolbars cover part of it while they show.
• dvh (dynamic) follows the toolbars, so it always matches the visible area, and changes while the reader scrolls.

vh was defined before phones did this, and browsers settled on the large viewport for it, so vh means lvh. Each height unit has width and logical twins (svw, dvi, lvmin and so on); on most phones the toolbars change only the height, so the width variants agree. The small, large and dynamic units are Baseline widely available. The numbers of a phone differ from model to model and browser to browser, so the program takes one example, a viewport 640 px tall with 56 px of toolbars:

// The small, large and dynamic viewport heights of CSS Values 4 on a phone whose browser shows its toolbars when the
// page opens and hides them while the reader scrolls. The heights are an example: every phone and browser has its own.

const viewport = { largeHeight: 640, toolbars: 56 };   // CSS px: the viewport with the toolbars hidden, their height
const smallHeight = viewport.largeHeight - viewport.toolbars;

const units = {
  '100vh': () => viewport.largeHeight,                   // vh is the large viewport
  '100lvh': () => viewport.largeHeight,
  '100svh': () => smallHeight,
  '100dvh': (shown) => (shown ? smallHeight : viewport.largeHeight),
};

console.log('unit     toolbars shown          toolbars hidden');
for (const [unit, height] of Object.entries(units)) {
  const row = [true, false].map((shown) => {
    const visible = shown ? smallHeight : viewport.largeHeight;
    const h = height(shown);
    const note = h > visible ? `${h - visible}px hidden` : h < visible ? `${visible - h}px gap below` : 'fits exactly';
    return `${h}px, ${note}`.padEnd(24);
  });
  console.log(`${unit.padEnd(8)} ${row.join('')}`.trimEnd());
}

// A full-screen hero with its 48px button at the bottom: is the button visible when the page opens?
for (const unit of Object.keys(units)) {
  const heroHeight = units[unit](true);
  const buttonTop = heroHeight - 48;
  console.log(`hero at ${unit}: button from ${buttonTop}px to ${heroHeight}px, ${heroHeight <= smallHeight ? 'visible' : 'behind the toolbars'} on opening`);
}

unit     toolbars shown          toolbars hidden
100vh    640px, 56px hidden      640px, fits exactly
100lvh   640px, 56px hidden      640px, fits exactly
100svh   584px, fits exactly     584px, 56px gap below
100dvh   584px, fits exactly     640px, fits exactly
hero at 100vh: button from 592px to 640px, behind the toolbars on opening
hero at 100lvh: button from 592px to 640px, behind the toolbars on opening
hero at 100svh: button from 536px to 584px, visible on opening
hero at 100dvh: button from 536px to 584px, visible on opening

A 100vh hero opens with its bottom 56 px behind the toolbars, which is often where its main button goes. 100svh fits on opening and leaves a 56 px gap once the toolbars hide. 100dvh always fits, at a cost the specification spells out: a box sized in dynamic units resizes while the reader scrolls, which can be distracting and costs layout work on every change. Browsers may also skip the in-between values while the toolbars animate. The on-screen keyboard usually doesn’t count as a toolbar: the specification gives it as the typical example of an interface that overlays the page without changing any viewport unit. A chat page that needs its input above the keyboard can ask for interactive-widget=resizes-content in its viewport <meta> tag, which resizes the viewport, and every viewport unit with it, in the browsers that support that key.

Follow the same 640px phone through the two toolbar states. The steps use the programme’s 56px toolbar value rather than assuming every phone has that much browser interface:

The small and large references stay at 584 and 640px. Only the dynamic reference changes with the toolbar state.

Choose a stable hero or a shell that follows toolbars

Start with the required behaviour rather than the newest unit. A hero should keep its main action in view when browser toolbars are expanded, then stay steady during a scroll. A shell can instead require its navigation to follow the current available height. These goals select different references even on the same phone.

The fallback uses declaration order. Put the large-reference vh declaration first and the small-reference svh declaration second. An engine that understands both selects the later one; an older engine discards the unfamiliar value and retains the earlier declaration. Reversing those lines would override the small-reference choice.

For widths, prefer 100% or a grid that spans the page to 100vw; use vi and vb when a component may meet vertical text; and never size text in viewport units alone.

Fit complete shells and full-width layouts Pro: opens with a Pro, Premium or Ultimate pass

Follow logical axes and test zoomed text Pro: opens with a Pro, Premium or Ultimate pass

Practise the viewport core

Interview questions

Fresher · What is the difference between 100vh, 100svh and 100dvh on a phone?

All three are a full viewport height, measured against different viewports. Phone browsers show toolbars when a page opens and hide them while the reader scrolls. 100svh is the small viewport, with the toolbars shown, so content that tall always fits, and leaves a gap once they hide. 100vh is the same as 100lvh, the large viewport with the toolbars hidden, so while they show, the bottom of the content sits behind them: 56 px of a 640 px screen in the lesson’s example, often where the main button is. 100dvh follows the toolbars and always matches the visible area, but it resizes while the reader scrolls. Use svh for heroes, dvh for app shells, and put 100vh first as a fallback.

Key takeaways

• vh and lvh use the large viewport; svh uses the small one, and dvh follows its dynamic size.
• Choose a stable small-viewport reference for a hero and a dynamic reference for a shell that must resize with toolbars.
• Widths and font sizes need their own reference decisions; a viewport unit does not fit every layout job.