When 100vh Isn’t the Screen: Understanding Mobile Viewport Issues in CSS

There’s a moment that catches many developers off guard.

You set:

height: 100vh;

And expect a perfect full-screen layout.

On desktop, it works exactly as you imagined.

On mobile…

something feels slightly off.

The bottom gets cut.

The layout shifts when you scroll.

Things don’t quite fit.

It’s subtle at first.

But once you notice it, you can’t unsee it.

The Assumption That Breaks

vh stands for “viewport height”.

So it feels natural to think:

“This is 100% of the screen.”

But on mobile, that assumption quietly breaks.

Because the “screen” isn’t a fixed thing.

A Screen That Keeps Changing

Mobile browsers are not just content containers.

They have their own interface:

• address bar at the top
• navigation bar at the bottom
• toolbars that appear and disappear

And these elements are not static.

They shrink.

They expand.

They hide when you scroll.

Which means the visible area of the page is constantly changing.

Two Versions of the Same Viewport

Behind the scenes, the browser deals with more than one idea of height.

There’s the full viewport—what the browser could show.

And there’s the visible viewport—what the user actually sees.

The difference between them is the browser UI.

And this is where things get interesting.

What 100vh Really Measures

Traditionally, 100vh is based on the full viewport.

Not the visible one.

So when the browser UI is visible, your layout becomes taller than the space the user can actually see.

The result?

Content gets pushed out of view.

Not because it’s wrong—

but because it’s measured against something larger than reality.

When the Layout Starts Moving

The issue becomes more obvious when you scroll.

As the browser UI hides, the visible viewport grows.

Now your layout suddenly “fits”.

But it didn’t change.

The viewport did.

So the page appears to jump.

Not dramatically.

But just enough to feel unstable.

Why This Happens

This behavior isn’t accidental.

Browsers chose consistency over accuracy.

By keeping vh tied to a stable value, they avoid constant recalculations during scroll.

But that stability comes at the cost of visual precision.

Especially on mobile.

A New Way Forward

To solve this, newer units were introduced:

• dvh — dynamic viewport height
• svh — small viewport height
• lvh — large viewport height

Each one reflects a different version of the viewport.

And for most cases, dvh is what developers expected vh to be all along.

height: 100dvh;

Now the height matches what the user actually sees.

Not what the browser could show.

A Subtle Shift in Thinking

This issue reveals something deeper.

The viewport is no longer a fixed boundary.

It’s responsive.

Not just to screen size—

but to user interaction.

Scrolling changes it.

UI visibility changes it.

And your layout has to adapt.

A Final Thought

100vh wasn’t wrong.

It just belonged to a simpler version of the web.

One where the viewport didn’t move.

But today, the screen is dynamic.

And once you understand that…

you stop thinking in fixed dimensions.

And start thinking in terms of what the user actually sees.