What Nobody Tells You About the Virtual Keyboard API: How to Finally Stop Your Mobile Forms From Being Buried

If you’ve ever had a mobile keyboard jump up and punch your layout in the face, you know the specific brand of frustration that comes with building mobile web forms. We spend weeks perfecting a UI only for the browser to shrink the viewport and hide the very "Submit" button the user needs to click.

For years, we’ve relied on the browser to "do the right thing" when a virtual keyboard appears. Usually, that means the browser shrinks the visual viewport, squishing your carefully crafted layout like an accordion. If you wanted to do anything custom, you had to jump through hoops with the Visual Viewport API, which often felt like trying to fix a leaking pipe while the water was already at your ankles.

Enter the Virtual Keyboard API. It changes the power dynamic from "the browser decides" to "the developer decides."

The Problem: The Browser Plays God With Your Pixels

By default, when a user taps an input, the browser handles the keyboard by resizing the window. This is why your bottom: 0 fixed-position footers suddenly fly up to the middle of the screen.

It’s jarring. It’s ugly. And until recently, it was unavoidable.

The Virtual Keyboard API introduces a property called overlaysContent. When you toggle this on, you’re telling the browser: "Don't touch my viewport. I'll handle the keyboard myself."

Step 1: Taking Control

First, we have to opt-in. This isn't the default behavior because, frankly, if the browser stopped resizing and you didn't provide a fallback, your inputs would just stay buried under the keyboard.

You enable it via JavaScript:

if ('virtualKeyboard' in navigator) {
  // This is the magic switch
  navigator.virtualKeyboard.overlaysContent = true;
}

Once overlaysContent is set to true, the browser stops resizing the layout. The keyboard now slides up *over* your content like a true overlay. But now you have a new problem: the keyboard is covering your UI.

Step 2: Using CSS Environment Variables

The real beauty of this API isn't just the JavaScript toggle; it’s the CSS integration. The browser gives us four new environment variables to track exactly where the keyboard is:

- keyboard-inset-top
- keyboard-inset-right
- keyboard-inset-bottom
- keyboard-inset-left
- keyboard-inset-width
- keyboard-inset-height

Most of the time, you only care about keyboard-inset-height. Here is how you use it to keep a "Next Step" button docked right above the keyboard:

.form-footer {
  position: fixed;
  bottom: 0;
  width: 100%;
  
  /* Use the keyboard height, or fallback to 0px if it's hidden */
  padding-bottom: env(keyboard-inset-height, 0px);
  
  transition: padding-bottom 0.3s ease;
  background: white;
  border-top: 1px solid #eee;
}

When the keyboard is closed, env(keyboard-inset-height) is 0px. When it slides up, the padding automatically expands to match the keyboard’s height. No more jumpy layouts; just a smooth transition that feels like a native app.

Step 3: Handling the Layout Like a Pro

If you have a long form, you don't want the bottom half to be inaccessible. You can use these variables to adjust your main container's height or padding so the user can always scroll to the last input.

main {
  display: flex;
  flex-direction: column;
  height: 100vh;
  /* Ensure the content isn't trapped behind the keyboard */
  margin-bottom: env(keyboard-inset-height, 0px);
}

The "Gotcha": It's Not Everywhere (Yet)

Before you go deleting all your legacy layout hacks, we need to talk about support. As of right now, this is a Chromium-led feature. It works beautifully in Chrome and Edge on Android and Windows.

What about iOS? Apple hasn't invited the Virtual Keyboard API to the party yet. On Safari, you’ll still be dealing with the classic viewport resize.

Because of this, you should always treat the Virtual Keyboard API as a progressive enhancement. Here’s a clean way to check for support and apply a specific class to your body:

if ('virtualKeyboard' in navigator) {
  navigator.virtualKeyboard.overlaysContent = true;
  document.body.classList.add('vk-api-supported');
}

Then in your CSS:

/* Standard behavior for Safari/older browsers */
.form-footer {
  bottom: 0;
}

/* Modern behavior for supported browsers */
.vk-api-supported .form-footer {
  bottom: env(keyboard-inset-height, 0px);
}

Why should you bother?

You might think, "Why go through the trouble if Safari doesn't support it?"

Because the difference in user experience is night and day. When you use overlaysContent, you stop the "layout thrashing" where every element on your page tries to recalculate its position at once. It makes your web app feel solid. It feels intentional.

Instead of fighting the browser's attempt to help you, you're giving the browser specific instructions on how to treat your design. It turns a chaotic mobile interaction into a controlled, polished experience.

Give it a shot on your next internal tool or Android-focused project. Once you see that footer slide up smoothly without the rest of the page shaking, you won't want to go back to the old way.