Detailed explanation
Viewport units size elements relative to the browser’s viewport: 1vh represents 1% of its reference height. Under the current CSS definition, vh corresponds to the large viewport unit, lvh. This reference assumes retractable browser interfaces, such as the mobile address bar, are hidden. By contrast, dvh means dynamic viewport height and uses a reference that changes as those interfaces expand or retract. The distinction matters most on mobile, where the space available for page content changes during scrolling.
With height: 100vh, an element fills the large viewport even when the address bar is visible. Consequently, its bottom can extend below the currently visible area, potentially hiding a call-to-action or introducing unwanted scrolling. Importantly, vh itself normally stays stable while browser chrome changes; it is not inherently the cause of repeated layout jumps. With height: 100dvh, the element tracks the changing viewport height, so its bottom more closely matches the available space. However, that resizing can itself create visible movement or trigger layout work during scrolling.
CSS also provides svh, the small viewport height, which assumes retractable browser interfaces are expanded. Choose svh when content must fit with browser controls visible and you want a stable height; choose lvh or vh when filling the largest viewport is intentional; choose dvh when adapting to changing browser controls is the priority. Dynamic does not guarantee smooth, frame-by-frame updates throughout a browser UI animation: browsers may throttle or defer updates. Also, dvh should not be assumed to shrink when an on-screen keyboard opens; keyboard behaviour depends on the browser and viewport configuration.
A progressive-enhancement pattern is .hero { min-height: 100vh; min-height: 100dvh; }. Browsers supporting dvh use the later declaration, while older browsers retain vh. For content-heavy heroes, min-height usually avoids the overflow problems of a fixed height by allowing the section to grow. In interviews, explain the trade-off between stable sizing and adaptive sizing, rather than presenting dvh as an unconditional replacement for vh.
Key points to remember
- 1vh equals 1% of the large viewport height under the current CSS definition, making vh equivalent to lvh.
- 100vh can exceed the visible mobile area when retractable browser controls are expanded.
- 100dvh adapts as browser controls expand or retract, but resizing may produce visible movement.
- svh provides a stable reference with browser controls expanded; lvh uses the reference with them retracted.
- Use a vh fallback before dvh, and prefer min-height when content must be allowed to grow.
Common mistakes candidates make
- Claiming that vh continually changes with the address bar and directly causes layout jumps.
- Assuming dvh updates smoothly every animation frame or always accounts for the on-screen keyboard.
- Applying height: 100dvh to content-heavy sections without considering overflow, text zoom, or a min-height alternative.
Likely follow-up questions
When would you choose svh instead of dvh?
Choose svh when you want a stable section height that fits while browser controls are visible. When those controls retract, additional space becomes available, but the section does not stretch to fill it.
Why declare vh before dvh?
A browser that does not understand dvh ignores that declaration and keeps the vh fallback. A supporting browser applies the later declaration because both declarations target the same property with equal cascade priority.
Does 100dvh guarantee that a form stays above the virtual keyboard?
No; virtual keyboards often resize the visual viewport without changing the viewport reference used by CSS viewport units. Test the target browsers and consider viewport configuration or the Visual Viewport API when keyboard-aware positioning is necessary.
Interview tip: Compare one mobile screen with its address bar visible and hidden, then explain why dvh improves fit but sacrifices height stability.