Differences Between lvh, svh, and dvh and How to Use Them: CSS Implementation Steps to Prevent Layout Breakage on Mobile Devices

For those struggling with issues like “the bottom gets cut off even though I set it to 100vh” or “the layout jumps when the address bar is displayed” on mobile sites, this article explains the differences between lvh, svh, and dvh, along with implementation steps. It covers not only the meaning of these units but also practical CSS examples you can use right away, verification procedures, and common pitfalls.

Target Audience for This Article

• Those who struggle with unstable heights when creating full-screen sections on mobile
• Those who find it difficult to control behavior using only the traditional `vh`
• Those who want to safely implement hero sections or fixed CTAs in WordPress themes or landing pages

Common Issues with `vh`

In mobile browsers, the height of the visible area changes depending on the display state of the address bar and toolbar. `100vh` may not align with these changes, leading to content being cut off, unwanted whitespace, or sudden jumps when scrolling.

To make it easier to solve this problem, `svh`, `lvh`, and `dvh` were defined in CSS Values and Units. The goal is to allow you to explicitly specify “which viewport state to use as the reference.”

Basic Overview of lvh, svh, and dvh

Unit	Reference	Recommended Use	Points to Note
svh	Minimum Viewport Height	UI elements you absolutely do not want to hide	There are situations where it appears to have excessive white space
lvh	Maximum viewport height	Screens that prioritize a wide display area	Parts of the UI may be hidden when displayed
dvh	Dynamic viewport height	Elements that need to adapt to changes in the display area	Recalculation occurs with state changes, which may cause perceptible flickering

`1svh`, `1lvh`, and `1dvh` each represent 1% of the corresponding viewport height. While the units themselves are simple, the user experience varies significantly depending on which screen elements they are applied to. It is important to use them appropriately for each specific purpose rather than simply replacing all elements with `dvh`.

Prerequisites

• Responsive HTML and CSS must already be in place
• Ability to test on the latest versions of major browsers
• If targeting older operating systems or WebViews, include a fallback

While current major browsers generally support `svh`, `lvh`, and `dvh`, user devices vary in real-world use. When retrofitting existing sites, it is safer to avoid removing all `vh` values immediately; instead, use `@supports` or multiple specifications to transition gradually.

Implementation Steps

Basic Fallback Configuration

First, create a foundation that is less likely to break in older browsers. The purpose is to establish a “base setting for sections with a height close to full screen.” Place `vh` first, and have `svh` or `dvh` override it in compatible browsers.

.hero {
  min-height: 100vh;   /* フォールバック */
  min-height: 100svh;  /* UI表示時も隠れにくい */
}

@supports (height: 100dvh) {
  .hero {
    min-height: 100dvh; /* 対応環境では動的追従 */
  }
}

Note that setting `height` to a fixed value can easily cause content to overflow depending on the amount of content. For hero sections and forms, it is more practical to use `min-height` as the baseline to avoid layout breaks when the main content expands.

Applying to Hero Sections

This is a case where we prioritize margin balance in the first view. Choose `svh` if you want to prioritize visual stability, or `dvh` if you want the section to follow the opening and closing of the address bar.

.hero {
  display: grid;
  place-items: center;
  padding: 24px;
  min-height: 100svh;
}

.hero--dynamic {
  min-height: 100dvh;
}

If a landing page contains a lot of animations, using `dvh` can cause noticeable re-layouts every time the UI changes. In such cases, set `.hero` to a fixed `svh` value and have only the background follow the changes in a separate element to reduce visual disruption.

Fixed CTAs and Forms

For input forms and fixed CTAs, the top priority is ensuring they “do not get hidden.” To include the bottom safe area, using `env(safe-area-inset-bottom)` in combination is effective.

.cta-fixed {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
  padding: 12px 16px calc(12px   env(safe-area-inset-bottom));
}

.form-screen {
  min-height: 100svh;
  padding-bottom: calc(16px   env(safe-area-inset-bottom));
}

Behavior when the keyboard is displayed is subject to differences in OS and browser implementations. On form screens, a layout that uses `svh` as the primary unit and applies `dvh` only to necessary elements is more effective at preventing unexpected jumps.

Functionality Testing

1. Open the page on an actual smartphone and check if any content is cut off on the initial view.
2. Scroll up and down to toggle the address bar visibility and check for changes in the hero section’s height
3. Open and close the keyboard in the form to ensure input fields and the submit button are not hidden
4. Rotate the screen and verify that the intended height is maintained in both portrait and landscape orientations
5. Verify that the `vh` fallback works on older devices and in WebViews

For safety, do not rely solely on DevTools emulation during testing. Since the behavior of the UI bar may differ from that on a physical device, we recommend testing on actual iOS Safari and Android Chrome devices at a minimum.

Troubleshooting

Height Jumping During Scrolling

Applying `dvh` to the entire layout can cause multiple elements to be recalculated simultaneously when the UI changes, resulting in a jerky appearance. This issue is often resolved by using `svh` for main containers and limiting `dvh` to only specific elements that need to visually follow the content.

Content Bottom Edge Hiding

If content overlaps with a fixed footer or home indicator, adjust the inner padding as well as the element’s height. Adding `env(safe-area-inset-bottom)` to `padding-bottom` can reduce device-specific clipping.

Issues with Older Environments

In some older environments, `dvh` may not work or may not recalculate as expected. It is safer to use a design that branches with `@supports (height: 100dvh)` and continues to use `vh` or `svh` in unsupported environments.

.panel {
  min-height: 100vh;
}

@supports (height: 100svh) {
  .panel {
    min-height: 100svh;
  }
}

@supports (height: 100dvh) {
  .panel--dynamic {
    min-height: 100dvh;
  }
}

Guidelines for practical usage

• Prioritize `svh` for UI elements you absolutely do not want to hide
• Use `dvh` locally for elements that need to adapt to screen changes
• Consider using `lvh` for layouts that prioritize a wide display
• For projects requiring compatibility, always include a `vh` fallback

Frequently Asked Questions

Is `vh` no longer necessary?

No, it is not. For projects that need to support older environments,vh it is practical to keep `vh` as a fallback. Implementing a solution that overwrites only environments compatible with the new units is the safest approach.

Is using only `dvh` sufficient?

It depends on the requirements.dvh While DVH offers high responsiveness, layout changes may be noticeable when the UI changes. For areas where stable display is a priority, svh may be easier to handle.

Are there practical use cases for lvh?

Yes. It’s effective for visually-focused sections where you want a wide display while the browser UI is minimized. However, since there’s a risk of elements being cut off when the UI is displayed, use it cautiously for critical interactive elements.

Does the same principle apply to WordPress themes?

Yes, it is. The key is to design by selecting units for each element, regardless of the template structure. Especially in themes with fixed headers or fixed CTAs,safe-area checking this in conjunction with other settings can help reduce issues.

Summary

`lvh`, `svh`, and `dvh` are units used to select which viewport state to use as the reference. When implementing, first set a `vh` fallback, then use `svh` for areas you don’t want to hide, `dvh` for areas you want to follow the user, and `lvh` for wide displays where visual presentation takes priority. Finally, by testing scrolling, keyboard interactions, and screen rotation on actual devices, you can significantly reduce layout breaks specific to mobile.