Understanding the vh unit in CSS: 1vh equals 1% of the viewport height

In CSS, 1vh equals 1% of the viewport height. It’s one of the viewport-relative units that helps pages breathe with screen size, making headers, sections, and modals scale with the visible area. Compare vh to vmin, vmax and note that rem ties to root font size rather than the viewport.

When you’re building layouts that feel right on every screen, the little details matter as much as the big ideas. One such detail is how we size elements relative to the visible area of a browser window. It sounds nerdy, but it’s incredibly practical: viewport-based units let you express sizes in terms of the screen you’re actually using. Think of it as giving your CSS a feel for the user’s real-world space rather than relying on static pixels.

Let me explain the basics with a simple mental image. Imagine you’re designing a hero section that should always fill the height of the screen, no matter if your reader is peeking at a laptop, a tablet, or a phone held up in a cozy cafe. You don’t want to guess how tall that space will be; you want it to adapt on the fly. That’s where viewport units come in. They’re CSS’s way of tying measurements to the size of the viewport—the visible portion of the page—so the design breathes with the device.

A quick tour of the main players

• vh: The one you’ll hear about most often. 1vh equals 1% of the viewport height. If the window is 1000px tall, 1vh is 10px. Using 100vh for a section makes it as tall as the screen. It’s the go-to choice when you want a full-screen section or proportional height that tracks the user’s viewport.

• vmin and vmax: These two are about the “viewport’s best fit.” vmin is 1% of the smaller dimension (width or height), while vmax is 1% of the larger dimension. They’re handy when you need a consistent scale that respects both axes, but you want to lean toward the smaller or the larger side as the viewport changes. For example, if you want a square-ish element that never grows taller than the narrowest edge, vmin has your back. If you want something that grows with the dominant direction, vmax is your friend.

• rem: This isn’t tied to the viewport at all. rem stands for “root em” and is based on the root font size (usually the 1rem equals the browser’s base font size, often 16px). It’s perfect for typography and spacing that should scale with user font preferences, but it won’t track the window’s height or width unless you couple it with other responsive techniques.

Why vh matters in responsive design

The beauty of vh is its simplicity. You can craft layouts that feel inherently responsive without juggling a dozen breakpoints, at least for certain tasks. If you want a hero banner to always be the height of the viewport, you set its height to 100vh. If you’re building a responsive modal that should take up a fraction of screen real estate, you can express that with a height like 60vh.

But there are caveats that’ll save you from some head-scratching moments:

• Mobile browser chrome can eat into the perceived viewport height. On phones, the address bar and toolbars might collapse or reveal themselves as you scroll, which can cause 100vh to seem taller than the visible space at times. This is especially noticeable on iOS Safari and some Android browsers. A practical workaround is to design with max-height: 100dvh instead of 100vh, where “dvh” stands for dynamic viewport height. It’s newer, so check for support, and be prepared to polyfill or fallback gracefully if needed.

• 100vh isn’t a guaranteed fixed number across all interactions. If your page has elements that trigger or hide chrome, the perceived height can shift during user interaction. That means you might see a jump or layout shift in a particularly tall hero section when the user focuses an input or a video goes fullscreen. Prepare for that by testing with real devices and considering CSS transitions that smooth out abrupt changes.

• Keyboard and input fields can affect the viewport on some devices. When a user taps a text field, the on-screen keyboard can resize the viewport, which makes strict height rules wobble a bit. In practice, you’ll often combine viewport units with flexible content flows and a bit of JavaScript if you’re chasing perfect stability in all scenarios.

• Font sizing and readability. While vh can make an element feel proportional to the screen, it’s not a one-size-fits-all solution for readability. Large blocks of text tied to viewport height can become awkward on very tall or very short screens. Pair vh with readable typography settings (dynamic line lengths, comfortable line-height, and accessible contrast) to keep the reading experience pleasant.

A few practical patterns you’ll actually use

• Full-height hero or landing sections. A classic use: a section that fills the screen, with content vertically and horizontally centered. Combine height: 100vh with display: grid and place-items: center for a clean, elegant look that remains consistent as the viewport changes.

• Proportional panels. Suppose you want a two-column layout where the left side stays visually dominant on wide screens but doesn’t overwhelm on narrow screens. You can set a height using vh for the right elements or use min-height: 50vh to ensure a minimum presence while allowing content to grow.

• Orchestrating behavior with min/max. You might set a maximum height with max-height: 80vh for a content block that shouldn’t grow too tall on large screens, then let its internal content scroll with overflow: auto. This keeps the layout tidy while still responsive.

A small detour into vmin and vmax

vmin and vmax can be especially handy in creative layouts where you want a consistent visual density across diverse devices. If you design a card grid where each card’s aspect ratio matters, vmin can keep those cards balanced as the viewport morphs. But if you’re aiming for a “dominant axis” effect—where width drives the feel on wide desktops, but height governs on phones—vmax can be your compass. They’re not as ubiquitous as vh, but they’re powerful when used thoughtfully.

Accessibility and considerations that surprise people

• Respect user preferences. Some users rely on reduced motion preferences. In such cases, heavy animations tied to viewport changes can be jarring. Keep animations optional and provide sensible fallbacks that don’t rely solely on motion to convey structure.

• Readability first. When you wire viewport units into typography or containers, test with real content. A headline that scales with viewport height is a neat trick, but the line length and word choice should stay readable. If a block of text becomes too tall or too short, readers will feel off-balance quickly.

• Consistency across devices. It’s tempting to chase a perfect percentage on every gadget, but the goal should be a consistent experience. Use a primary responsive strategy—often a blend of fluid typography, relative units, and a few well-chosen breakpoints. Reserve viewport units for cases where they genuinely improve the feel and flow.

• Performance matters. Viewport-based sizing is inexpensive at compute time, but if you combine it with heavy heavy visuals, animations, or lots of reflows, you can end up with a choppy UI. Keep your CSS lean and test on devices with limited resources.

Patterns you’ll encounter in real-world projects

• A splash screen that fades into content. A hero that starts at 100vh and then animates down as the user scrolls can create a memorable entry. The trick is to ensure that the initial state doesn’t block critical content and that the transition feels natural rather than forced.

• Cards and galleries with responsive rhythms. When cards must stay proportionate as the viewport shifts, using a combination of minmax() in grid layouts with vh-based heights on media elements can yield a cohesive grid that feels intentional across sizes.

• Full-bleed imagery. Sometimes a dramatic, edge-to-edge photo is your best storytelling tool. A container with height: 100vh and overflow: hidden ensures the image fills the screen without stretching excessively, while object-fit: cover keeps the composition intact.

Common pitfalls, and how to sidestep them

• Forgetting about the fallback. Not all environments support newer viewport units or dynamic viewport height. Always include a sensible fallback—prefer solid, predictable layouts with basic units, and then layer in viewport-specific niceties for browsers that support them.

• Neglecting mobile quirks. On mobile, toolbars and address bars can change. If you rely solely on 100vh for critical UI, you’ll end up with odd gaps or clipped content. A layered approach (progressively enhancing from simple to complex) helps keep things resilient.

• Overusing viewport units. It’s tempting to go all-in, but you don’t want to box yourself into a corner where every measurement is forced by the viewport. Use vh, vmin, or vmax where they genuinely improve the experience, and rely on rem and percent-based sizing for the rest.

A few practical tips you can try today

• Start with a baseline. Create a hero or a hero-like container with height: 100vh, background visuals, and a clean typographic rhythm. Then adjust with min-height and padding to accommodate heading or button sizes, ensuring no awkward overflow.

• Test across devices. Use browser dev tools to simulate various viewport sizes, but don’t stop there. If possible, test on a couple of real devices. The way a page feels when you swipe on a phone vs. a desktop experience can be quite different.

• Combine with fluid typography. Pair viewport-based sizing with responsive font sizes. A common pattern is to set font sizes with clamp(), which lets you define a minimum, preferred, and maximum size across viewports:

clamp(1rem, 2.5vw, 2rem)

This approach keeps text legible without letting it balloon or shrink too far.

• Embrace progressive enhancement. Start with robust, accessible defaults, then layer in viewport-aware refinements. If something doesn’t work everywhere, have a plan to gracefully degrade or adapt.

A friendly takeaway

Viewport-based units aren’t a magic wand, but they’re a practical tool in a designer’s toolbox. They give you a way to speak the screen’s language, to design with a sense of space that adapts as the user moves from a laptop to a phone to a big monitor. It’s not about chasing a perfect pixel count; it’s about feeling out the rhythm of a page and letting the layout breathe in harmony with the device.

If you’re curious to try, grab a small project and sketch a layout that uses 100vh for a hero, a few elements set with min-height: 60vh for panels, and a couple of images that use object-fit: cover to keep composition intact. See how the sections rearrange themselves as you resize the window. You’ll notice the page becoming more than just a static stack of blocks—it starts to feel like a living, breathing canvas that respects the viewer’s space.

As you experiment, you’ll also discover what they don’t tell you in quick tutorials: the subtle dance between typography, contrast, and space, and how viewport-based decisions influence the overall vibe of a site. It’s a small set of tools, but when used with intention, they can help you craft experiences that are not only visually appealing but also comfortable and usable in the real world.

So go ahead: play with vh, explore vmin and vmax where they fit, and keep rem for the scales that should feel timeless. Let the viewport guide your instincts, but always keep the reader—the person on the other side of the screen—in mind. After all, the best interfaces feel obvious, almost casual, even when they’re quietly clever beneath the surface. And that’s the charm of responsive design: the page that grows with you, not the other way around.