Viewport units — vw and vh — are powerful CSS tools for building layouts that adapt to any screen size, without a single media query. Instead of guessing pixel breakpoints, you tie an element's size directly to the browser window itself.
What is VW (Viewport Width)?
1vw equals 1% of the browser window's width. If the viewport is 1200px wide, 1vw = 12px. Set width: 50vw on an element and it's always exactly half the browser window wide, whether that window is 400px or 4000px.
What is VH (Viewport Height)?
1vh equals 1% of the browser window's height. If the viewport is 900px tall, 1vh = 9px. This is the go-to way to make a section fill the entire screen: height: 100vh.
How to Calculate VW and VH Values
Viewport units are simple percentages, so converting between them and pixels takes one line of arithmetic:
- vw to px: px = vw Ă— viewport width Ă· 100
- px to vw: vw = px Ă· viewport width Ă— 100
- vh to px: px = vh Ă— viewport height Ă· 100
- px to vh: vh = px Ă· viewport height Ă— 100
Worked example: a design mockup is 1440px wide and has a 360px sidebar. 360 Ă· 1440 Ă— 100 = 25vw. On a 1920px monitor that same 25vw becomes 480px; on a 1024px laptop it becomes 256px. For height, a 600px hero on a 900px-tall mockup is 600 Ă· 900 Ă— 100 = 66.67vh.
The key thing to remember is that the result is only “correct” at the viewport size you calculated it for. Everywhere else it scales, which is exactly the point — but it also means you should check the extremes (a 320px phone and a 2560px monitor) before shipping. Our VW to PX and VH to PX converters let you check what a value will resolve to at any screen size.
VW vs Percentage: What’s the Difference?
It’s easy to assume 50vw and 50% are the same thing. They aren’t:
| Unit | Relative to | Typical use |
|---|---|---|
% (width) | The width of the parent element | Columns and components inside a container |
vw | The width of the browser viewport | Full-bleed sections, fluid type, elements that must ignore their container |
% (height) | The parent’s height — only if the parent has an explicit height | Rarely reliable on its own |
vh | The height of the browser viewport | Full-screen sections, sticky panels, modals |
That last row is why vh became popular: height: 100% does nothing unless every ancestor up to html has a defined height, while height: 100vh works anywhere. If you want to understand what “the viewport” actually is — and how the viewport meta tag affects it — see our guide on what the viewport is in CSS.
Common Use Cases
- Full-screen hero sections —
min-height: 100vhon the first section of a landing page. - Fluid typography —
font-size: 4vwscales headline text smoothly with the window, though it's best combined withclamp()so text doesn't shrink to unreadable sizes on small screens:font-size: clamp(1.5rem, 4vw, 3rem). - Square or fixed-ratio elements —
vminkeeps a shape's proportions consistent regardless of orientation.
VMin and VMax
vmin resolves to 1% of whichever is smaller — width or height — and vmax to 1% of whichever is larger. They're useful when you want something to scale consistently whether the device is in portrait or landscape, such as a circular badge or a modal that should never be taller than the screen: max-height: 90vmin.
The 100vh Problem on Mobile
On mobile Safari and Chrome, 100vh is calculated against the tallest the viewport could possibly be — including the space hidden behind the browser's address bar and toolbar. That means a section styled with height: 100vh often extends past what the user can actually see, cutting off a footer or call-to-action button below the fold.
Newer dvh (dynamic viewport height), svh (small viewport height), and lvh (large viewport height) units solve this by tracking the browser chrome as it shows and hides. For a full-screen section that behaves correctly today across old and new browsers, stack the fallback: height: 100vh; height: 100dvh;
| Unit | Measures | Best for |
|---|---|---|
svh | The viewport with the browser toolbars fully shown (the smallest it gets) | Content that must always be visible, such as a hero with a button at the bottom |
lvh | The viewport with the toolbars fully hidden (the largest it gets) | Backgrounds that should never show a gap when toolbars retract |
dvh | The current viewport, updating as toolbars appear and disappear | Full-screen app layouts that should always match what is visible |
The same three prefixes exist for width (svw, lvw, dvw) and for vmin/vmax, although width rarely changes when toolbars move. A practical pattern:
.hero {
min-height: 100vh; /* fallback for older browsers */
min-height: 100svh; /* never taller than the visible area */
}
.app-shell {
height: 100dvh; /* tracks the toolbar as it moves */
}Prefer svh for most hero sections. Because dvh recalculates as the user scrolls and the toolbar collapses, large elements sized with it can resize mid-scroll and make content below them jump.
Fluid Typography with clamp() and VW
Pure vw font sizes have two problems: they get tiny on phones and huge on wide monitors, and they don’t grow when a user zooms in, because zooming shrinks the viewport in CSS pixels. Mixing a rem value into the calculation and capping it with clamp() fixes both:
h1 {
font-size: clamp(1.75rem, 1rem + 2.5vw, 3rem);
}With a 16px root font size, here’s what that resolves to:
- 375px phone: 16 + (2.5 Ă— 3.75) = 25.4px, below the 28px minimum, so the heading is 28px.
- 1024px laptop: 16 + (2.5 Ă— 10.24) = 41.6px, within range.
- 1920px monitor: 16 + 48 = 64px, above the 48px maximum, so it caps at 48px.
The 1rem part keeps the size tied to the user’s browser font setting, so text still responds to accessibility preferences.
Common Mistakes with Viewport Units
- Using
width: 100vwfor full-width sections. On desktop browsers with classic (non-overlay) scrollbars,100vwincludes the vertical scrollbar, so the element is roughly 15–17px wider than the visible page and triggers a horizontal scrollbar. Usewidth: 100%on a block element instead. - Using
height: 100vhinstead ofmin-height. A fixed height clips content when the text wraps onto more lines on small screens.min-heightlets the section grow. - Sizing body text in vw alone. As shown above, it breaks zoom and becomes unreadable at the extremes. Always clamp it.
- Forgetting landscape phones. A phone in landscape may be only around 350–400px tall, so a
100vhsection with a lot of content overflows quickly. Test both orientations. - Using vh for spacing everywhere. Padding like
10vhlooks fine on a laptop but becomes enormous on a tall portrait monitor. Fixed or rem-based spacing is usually more predictable.
Need to convert a fixed pixel measurement into a viewport unit for a specific breakpoint? Our PX to VH and PX to VW converters do it instantly. Building a layout around a specific screen ratio instead? Try our Aspect Ratio Calculator. For the bigger picture of how viewport units fit alongside media queries and fluid grids, read What is Responsive Web Design?
Frequently Asked Questions
Are dvh, svh and lvh safe to use today?
Yes. They are supported in current versions of Chrome, Edge, Firefox and Safari. Older browsers ignore a declaration they don’t understand, which is why writing a vh line first and the newer unit second works as an automatic fallback.
Does the on-screen keyboard change vh on mobile?
Generally not. In iOS Safari and current Chrome for Android, the keyboard overlays the page by default rather than resizing the layout viewport, so vh, svh and dvh keep the same value. Chrome lets you change that behaviour with the interactive-widget setting in the viewport meta tag.
Do viewport units work inside an iframe?
Yes, but they are relative to the iframe’s own viewport, not the parent page. 100vh inside a 400px-tall iframe is 400px.
Should I use vw or rem for layout widths?
Use vw when a size genuinely should track the screen, such as full-bleed banners or fluid type. Use rem or % with a max-width for readable content columns, because line length should stay comfortable rather than grow forever on wide screens.
Try it yourself: take one pixel value from your current design, convert it with the PX to VW converter, then resize your browser window and watch how the element scales between your smallest and largest target screens.