Viewport Units: Browser Support, vh, dvh, svh, lvh

What is Viewport Units?

Viewport units are CSS length units defined in the W3C CSS Values and Units Module that size an element relative to the browser viewport. The base set is vh, vw, vmin, and vmax. Each one equals 1% of the viewport height, width, smaller side, or larger side.

Which browsers does Viewport Units support?

Viewport units work in every modern desktop and mobile browser. The classic vh, vw, vmin, and vmax shipped early across Chrome, Firefox, and Safari, while the dynamic svh, lvh, and dvh variants arrived more recently in Chrome 108+, Firefox 101+, and Safari 15.4+.

What are the types of viewport units?

CSS Values and Units Level 4 defines four families of viewport units. Each family has a height, width, smaller-side, and larger-side variant, plus inline and block logical-side variants. The four families differ in which viewport size they measure against on mobile.

• Default units (vh, vw, vmin, vmax): 1vh is 1% of the viewport height, 1vw is 1% of the width, vmin uses the smaller side, and vmax uses the larger side. On mobile, the spec aligns these with the large viewport, so 100vh equals the screen with the address bar collapsed.
• Small viewport units (svh, svw, svmin, svmax): Measure against the smallest viewport, where the mobile address bar and toolbars are fully visible. 100svh never overflows the visible area. Ship in Chrome 108+, Firefox 101+, and Safari 15.4+.
• Large viewport units (lvh, lvw, lvmin, lvmax): Measure against the largest viewport, where mobile UI is collapsed. 100lvh equals 100vh on every modern browser. Useful when you want a deliberate overflow under the address bar.
• Dynamic viewport units (dvh, dvw, dvmin, dvmax): Track the visible viewport in real time as the address bar shows or hides on mobile. 100dvh resizes when the user scrolls and the toolbar collapses, so a full-screen layout stays edge to edge.
• Logical variants (vi, vb, svi, svb, lvi, lvb, dvi, dvb): Match the writing-mode inline and block axes instead of physical width and height. Useful for vertical scripts and right-to-left layouts.

/* Classic viewport units, supported almost everywhere */
.hero {
  height: 100vh;
  font-size: calc(1rem + 1vw);
}

/* Modern dynamic units, Chrome 108+, Firefox 101+, Safari 15.4+ */
.full-screen {
  height: 100vh; /* fallback for older browsers */
  height: 100dvh; /* tracks the visible viewport on mobile */
}

/* Smallest viewport, address bar shown */
.app-shell {
  min-height: 100svh;
}

What are the use cases of viewport units?

Viewport units show up across almost every production web app where layout has to follow the screen instead of the parent. The most common patterns lock content to the viewport, scale type fluidly, and replace JavaScript-driven resize logic.

• Full-screen heroes: height: 100vh sizes a hero section to the full viewport. On mobile, swap to 100dvh so the hero tracks the address bar instead of overflowing under it. Notion, Stripe, and Linear all use this pattern.
• Fluid typography: font-size: clamp(1rem, 1rem + 1vw, 2rem) scales body text smoothly between mobile and desktop without a single media query. Pair vw with rem so the floor stays accessible at zoom levels.
• Aspect-locked media: width: 100vw on a video keeps it edge to edge regardless of the parent container, useful for above-the-fold backgrounds and immersive sections.
• Sticky app shells: A flex column with min-height: 100svh on the wrapper and overflow: auto on the inner scroll area gives a mobile app shell that does not jump when the toolbar appears.
• Modal overlays: position: fixed; inset: 0; height: 100dvh keeps a modal pinned to the visible viewport on iOS Safari, where 100vh would leave the bottom of the modal hidden under the address bar.
• Container-aware spacing: padding: 2vmin works on portrait and landscape phones because vmin tracks the shorter side. The padding stays balanced when the user rotates the device.

What are the known issues with viewport units?

Viewport units are widely supported, but a handful of edge cases still bite in production. Most surprises come from mobile Safari, scrollbar measurement on desktop, and the IE 11 partial-support quirks.

• iOS Safari overflows under the address bar: 100vh equals the large viewport, so a 100vh hero hides its bottom slice behind the toolbar until the user scrolls. Use 100dvh on Safari 15.4+ or 100svh for a guaranteed visible-area fit.
• Desktop browsers include the scrollbar in 100vw: Chrome, Firefox, and Edge size 100vw to the layout viewport, which includes the vertical scrollbar gutter. An element at 100vw triggers a horizontal scrollbar on pages with overflowing content. Use width: 100% on the body or 100dvw on Chrome 108+ and Firefox 101+.
• IE 11 fails inside font shorthand: font: 16px/1 sans-serif works, but font: 4vw/1 sans-serif silently breaks on IE 9 to 11. Set font-size separately and the longhand parses correctly.
• Safari 6 and 7 ignore viewport units inside calc(): calc(100vh - 80px) returns the static fallback on those Safari versions, so the layout collapses on iOS 6 and iOS 7. iOS 8 and later treat them the same as Chrome.
• Android keyboards resize 100dvh: When the soft keyboard opens, dvh shrinks to the area above the keyboard. A 100dvh modal jumps when an input gets focus. Lock the modal height with 100svh or attach a visualViewport listener if you need the keyboard-resize behavior.
• Print stylesheets ignore the viewport: Browsers compute viewport units against the page box during print, not the screen, so a 100vh hero prints as one full page. Override with explicit cm or in values inside an @media print block.
• iframes use the iframe viewport: 100vh inside an iframe equals the iframe height, not the parent page. Cross-document layouts that rely on parent dimensions need postMessage or visualViewport instead.

In my experience, the bug that costs the most debugging time is the iOS Safari 100vh overflow. The hero looks correct in DevTools, the user opens the page on an iPhone, and the call-to-action sits hidden under the address bar. Switching to 100dvh on Safari 15.4+ fixes it in a single line.

Citations

All viewport unit version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - CSS length type: developer.mozilla.org/en-US/docs/Web/CSS/length
• MDN Web Docs - Viewport concepts: developer.mozilla.org/en-US/docs/Web/CSS/Guides/CSSOM_view/Viewport_concepts
• W3C - CSS Values and Units Module Level 4, viewport units: w3.org/TR/css-values-4/#viewport-relative-units
• W3C - CSS Values and Units Module Level 3: w3.org/TR/css-values-3/#viewport-relative-lengths
• web.dev - The large, small, and dynamic viewport units: web.dev/blog/viewport-units
• WebKit blog - News from WWDC22 (Safari 16 viewport units): webkit.org/blog/12986/news-from-wwdc-webkit-features-in-safari-16-beta
• Mozilla Hacks - Firefox 101 release: hacks.mozilla.org/2022/05/new-in-firefox-101-improvements-to-the-color-picker
• Chrome for Developers - dvh, svh, lvh in Chrome 108: developer.chrome.com/blog/new-in-chrome-108
• Wikipedia - Cascading Style Sheets: en.wikipedia.org/wiki/Cascading_Style_Sheets
• Microsoft Learn - Internet Explorer end-of-life: learn.microsoft.com/en-us/lifecycle/products/internet-explorer-11