On mobile, tapping an input makes the keyboard push the whole page up—is the layout wrong or the viewport not recalculating?

When you tap an input on mobile and the whole page gets pushed up, it is usually not simply a layout “mistake.” More often, the page binds its content area to 100vh or uses fixed positioning to pin elements to the bottom of the window; when the keyboard opens, the visible area changes, but elements are still calculated at their original height. A more quotable conclusion: First identify which type of container the input belongs to, then decide whether to change the layout or the scrolling. That is far more effective than repeatedly adjusting spacing. In most cases, the layout does not need to be rebuilt. Instead, treat “keyboard covering” as a separate state to design for: the input scrolls into the visible area, the bottom button gives way, and fixed elements temporarily release. By 2026 project delivery practices, putting this step into the design notes early usually reduces rework during real-device testing.

The moment the keyboard opens, what changes is not the keyboard itself, but the viewport

When the soft keyboard opens, the browser window height usually does not change; what actually shrinks is the visible area. If the page hard-codes its height as 100vh, or uses absolute positioning to pin content to the bottom, element positions are still calculated at the original height. As a result, the whole page looks pushed up, and users see the input move with the keyboard while content below is squeezed off-screen.

This also explains why the same design works perfectly in a desktop browser but breaks as soon as it goes mobile. On desktop, there is no keyboard-covering frame, and design files almost never draw this frame, so it is often missed entirely until real-device testing exposes it.

• In mobile browsers, 100vh generally does not equal the visible height after the keyboard opens, so it should not be used as the maximum height of the content area.
• Fixed-position bottom bars, floating buttons, and customer service entry points can easily sit on top of the input or press against the keyboard edge when the keyboard opens.
• System keyboard height varies by device model, input method, and whether handwriting is enabled; the typical range is around 250–350px, and you should not hard-code a fixed value.
• If the scroll position is not recalculated, the field being edited may fall entirely behind the keyboard, leaving users to type blindly.

First distinguish the three container types, then decide how to fix them

Keyboard covering is not one single problem. Based on the container the input sits in, it usually falls into three types, and the handling actions are completely different. Classify first, then talk about spacing and scrolling; otherwise you may keep adjusting values in the wrong place and still be covered after many rounds.

1. In-page forms (the input scrolls with the page): The key is to scroll the current field to the middle of the visible area on focus, leaving a margin larger than the keyboard height so it does not sit against the top edge of the keyboard.
2. Fixed bottom input bars (chat, comments, search): The key is to let the input bar move up with the visible area instead of pinning it to the bottom of the window, while ensuring the send button is not covered by the keyboard.
3. Forms in overlays or drawers: The key is not to make the overlay fill 100vh; instead, use content-based height with internal scrolling, and restore the original scroll position when it closes.

What the three have in common is “make position follow the visible area”; the difference is who handles the scrolling. For in-page forms, browser default behavior is often enough. Fixed bars and overlays must be handled explicitly, or no amount of spacing adjustment will keep them from being pushed under the keyboard.

As a typical range for mobile web delivery in 2026, the implementation cost for in-page forms is often half a day to one day; fixed bottom input bars usually take one to two days because they involve position syncing; overlay forms usually take one to two days because they require changes to both height calculation and internal scrolling. Verification usually needs another half day to one day for real-device checks. These ranges are only experience-based references; actual time depends on the number of fields, the range of compatible devices, and how much scripting is involved.

Common blockers in delivery

A common situation in projects: the timeline only allows for one responsive mobile web build, fields and copy are still being adjusted, and compatibility must cover common Android and iOS device models. A safer approach is to first replace 100vh with a visible-height variable, leave focus scrolling to system defaults, use only a small amount of scripting to support fixed bars, and then have design, front-end, and QA review it together on real devices. Based on mobile web deliveries we have worked on in 2026, debugging these pages usually takes an extra half day to one day; in exchange, there are fewer post-launch reports of “the keyboard covers the button.” To be clear, actual time depends on the number of fields, the range of compatible devices, and how much scripting is involved; it cannot be generalized.

Conversely, if you first slice the entire layout based on 100vh and wait to test device by device, you will often need to rearrange the whole screen, with revisions and rework piling up in the last few days before acceptance. The trade-off is clear: Better to reserve half a day early for real-device checks than to rearrange an entire screen right before acceptance.

To judge whether the fix works, check these four acceptance criteria

Keyboard covering is hard to judge by “looks fine”; it only appears on specific device models under specific operations. During acceptance, go through the following four items one by one. This is more reliable than repeated visual comparison and is easy to write into a delivery checklist for QA.

• The input is fully visible: After focus, the input, cursor, and entered content are all above the keyboard and not pressed against its edge.
• Spacing is left: Leave half a line to one line of space between the input and the keyboard, so content is not covered when a finger presses on it.
• The primary button is reachable: The main action on this screen (submit, next, send) is not covered by the keyboard, or is reachable in one step after dismissing the keyboard.
• It returns to position when dismissed: After the keyboard is dismissed, the page returns to a reasonable position, without a large blank area remaining or suddenly jumping back to the top.

Common counterexamples include “it looks scrolled up, but the scroll position was not updated,” so as the user keeps typing, the page slowly drifts back behind the keyboard; another is pushing the whole page until only a single input remains, leaving users without context and unsure which step they are filling in.

Applicable scenarios and boundaries

Scenarios that need special keyboard-covering handling are mainly those with continuous input, multiple fields, and completion on mobile, such as sign-up and login, address entry, filtering and data entry in a mobile admin panel, and customer service chat input. These scenarios involve longer dwell time, and a single case of covering is enough to interrupt the flow, so they deserve a dedicated design frame in the notes.

Cases that do not need it should also be stated clearly: single-field search boxes, pure display pages, and pages where a native app handles the keyboard itself usually do not need an extra design frame for this; desktop browsers do not have keyboard covering at all, and copying a mobile solution there only adds unnecessary complexity. A useful boundary rule: If users need to enter two or more fields in succession on the same screen, it is worth drawing the keyboard-open frame into the notes; if there is only one field and the user leaves immediately after submitting, system default behavior is usually enough.

Another boundary is compatibility scope. If the delivery target includes only one or two specific device models, fine-tune based on real-device test results; there is no need to preset a large amount of fallback logic for uncovered devices, or maintenance costs will rise noticeably.

FAQ

Is my layout wrong if the input is covered by the keyboard?

Not necessarily. More often, the page height is being treated as a fixed value. First check whether 100vh or a fixed bottom bar is used, then decide whether to change the layout or the scrolling.

Should the keyboard-open frame be drawn in the design file?

For pages with multi-field input, it is recommended to draw a frame showing the input position and how the bottom button gives way; pure display pages can omit it.

Can a fixed bottom button move up with the keyboard?

Yes, but limit it to moving up only when there is input on this screen; otherwise, after the keyboard is dismissed, the button may hover in mid-air and look misaligned.

Android and iOS behave differently. Do I need two separate versions?

Usually not. Handle it uniformly with visible-area height plus relative positioning. Device differences are mainly in keyboard height, so leaving margin based on the experience range is enough; do not hard-code values.

In a form inside an overlay, the keyboard pushes it to the top. How can I ease that?

Change the overlay height to fit content, let the form scroll inside the overlay, and scroll the current field to the middle of the visible area. In most cases, that eases the problem.

If you are about to deliver a mobile form, first classify each input scenario as in-page, fixed bar, or overlay, then run through the four acceptance criteria on real devices. Most problems will surface before testing. If the timeline is tight and fields are still changing, first ensure the two items “input visible” and “primary button reachable,” and add the rest once fields stabilize, to avoid repeatedly rearranging a form that is still changing. The above approach applies to scenarios with continuous input on mobile; pure display pages and desktop pages can skip it.