A mobile page can fit perfectly until the keyboard opens. A desktop dialog can fit at normal zoom and become unreachable when the user enlarges the page. Both failures often come from treating screen size, layout viewport and visible viewport as the same measurement.
They describe different things. The screen belongs to the display environment. The layout viewport is the space used for much of CSS layout. The visual viewport describes the portion currently visible, which can change with pinch zoom and on-screen interface elements. Diagnose the dimension that actually controls the failing component.
Begin with CSS pixels
A CSS pixel is a layout unit, not a promise about one physical display pixel. Device pixel ratio relates CSS pixels to device pixels under the current environment. Display scaling, page zoom and movement between screens can affect that relationship. A screenshot's bitmap dimensions therefore do not necessarily equal the page's CSS dimensions.
The viewport inspector reports screen dimensions, available screen area, window dimensions, device pixel ratio and visual viewport information when exposed. Run it in the same browser window where the problem occurs. A report from a maximised window does not explain a failure in a narrow split-screen window.
Record orientation and zoom too. The same device can have several useful layout states, and users can enlarge content without changing hardware. A design that works only at the developer's default scale has not been tested at the actual conditions where content becomes difficult to reach.
Match each dimension to a question
Screen width can help describe the environment, but it is a poor basis for deciding whether a component fits inside the current browser window. innerWidth describes the window's layout viewport and can include a scrollbar. The document element's clientWidth often provides another useful comparison when investigating that scrollbar space.
The visual viewport can be smaller than the layout viewport during pinch zoom or when a mobile keyboard changes the visible area. Its width, height, scale and offsets help explain which portion of the page is visible. Browser behaviour varies, so record actual values on supported target devices.
Available screen dimensions describe screen space available to windows after some system interface areas are considered. They do not guarantee the browser occupies that space. A docked developer panel, browser sidebar or operating system window arrangement can reduce the content area independently.
| Question | Useful measurement | Common mistake |
|---|---|---|
| Does this layout fit the window? | Layout viewport width | Using physical screen resolution |
| What is visible above the keyboard? | Visual viewport height and offsets | Assuming the full layout height remains visible |
| Why is a canvas blurry? | CSS size and device pixel ratio | Changing only its displayed size |
| Where did the scrollbar come from? | Document scroll width and client width | Hiding overflow before finding the element |
| Why did zoom change the layout? | Viewport, scale and current zoom context | Assuming hardware dimensions are fixed CSS values |
Reproduce a keyboard failure step by step
Open the affected form on a real mobile browser and record the viewport before focusing an input. Focus the field, wait for the keyboard to settle and record the values again. Note whether the browser resizes the layout viewport, changes only the visual viewport or overlays content under the keyboard.
Consider a checkout page with a fixed confirmation bar. Before keyboard opening, the bar fits at the bottom of the window. Afterwards, the visible area is shorter and the bar can cover the active field or sit behind the keyboard. A hard-coded height based on the initial page load will not describe this later state.
Check whether the input and confirmation action remain reachable by scrolling. Then rotate the device and repeat with a long validation message. The message changes content height, while the keyboard changes available space. Testing only an empty form misses the combination that often causes the actual failure.
Use the browser's supported viewport and layout features to respond to these changes, and test the resulting behaviour. Do not assume one keyboard-height constant works across languages, suggestion bars and input types. A numeric keyboard can occupy a different area from a full text keyboard.
Choose viewport height units deliberately
Traditional viewport height units have a history of surprising behaviour around mobile browser controls. Newer small, large and dynamic viewport units provide more explicit choices for the browser interface states they describe. They are useful, but they do not remove the need to test the keyboard and embedded contexts.
A full-screen panel may benefit from a minimum height that allows content to grow, instead of a fixed height that clips a long form. Combine layout rules with ordinary document flow where possible. When a component must be fixed, define how its contents scroll and how the user reaches its close or submit control.
Inspect the computed value on target browsers. A rule that works on a desktop emulator can behave differently on a mobile device with browser chrome and a software keyboard. Keep an explicit fallback for unsupported units and ensure the fallback still permits access to all content.
Find the element that creates horizontal overflow
Compare document scroll width with the viewport width. If the document is wider, inspect elements whose bounding boxes extend beyond the right or left edge. Common causes include fixed-width tables, long unbroken tokens, minimum widths on flex children and code blocks that do not have their own scroll container.
For a technical article, keep the page itself within the viewport and let a wide table or code block scroll inside its own container. That preserves the data without forcing the entire page sideways. Use wrapping for ordinary prose and URLs where a line break does not change the meaning.
Do not immediately apply overflow-x hidden to the whole page. It can conceal the symptom while cutting off a menu, focus outline or control. First identify whether the extra width belongs to content that should wrap, a component that should shrink or a deliberately scrollable region.
Keep a canvas sharp without confusing its sizes
A canvas has a bitmap size and a CSS display size. If a 300 by 150 bitmap is displayed at twice that size, the browser stretches the existing pixels. For a sharper result, an application can allocate a backing bitmap based on the display size and device pixel ratio, then scale its drawing coordinates appropriately.
That choice increases memory and rendering work. Doubling both bitmap dimensions creates four times as many pixels. A high-density display can therefore make an otherwise simple animation expensive. Measure the application's workload and consider a sensible resolution limit for large visualisations.
When diagnosing a fingerprint or screenshot difference, record both dimensions. Two canvases that look the same size can contain different numbers of pixels. A digest of their raw buffers will differ because the measured inputs differ, even before considering rendering details.
Calculate the backing bitmap before allocating it
A chart displayed at 600 by 400 CSS pixels has 240,000 CSS pixel positions. At a chosen backing scale of two, its bitmap becomes 1,200 by 800, or 960,000 pixels. A four-channel byte buffer for that bitmap takes about 3.66 MiB before other graphics resources are counted.
At a scale of three, the bitmap contains 2,160,000 pixels, nine times the scale-one count. This explains why a chart can become expensive on a dense display despite having the same visible size. It also explains why comparing only the CSS width can miss a performance regression.
Recalculate when the container changes size, and avoid allocating a new bitmap on every insignificant event. A resize observer with careful update scheduling can keep the chart aligned with its container while limiting repeated work. Check text sharpness and interaction coordinates after scaling.
Frequently asked questions
Is device pixel ratio a reliable device identifier?
No. Many devices share the same value, and browser zoom or display configuration can affect it. Use it as an input to rendering decisions when appropriate, not as a hardware identity. The viewport report describes the current environment and does not establish who is using the browser.
Why does pinch zoom leave some CSS breakpoints unchanged?
Pinch zoom can change the visual viewport while leaving the layout viewport used by media queries unchanged. The user sees a smaller portion of the existing layout. Desktop page zoom may affect layout differently. Record both viewport measurements and the zoom method before comparing behaviour across browsers.
Should I disable zoom to prevent layout problems?
Fix the layout so enlarged content remains usable. Zoom is an important reading and accessibility control. Preventing it can make a page difficult to use without resolving fixed-width components or unreachable controls. Test content enlargement, long text and keyboard access as part of the same layout review.
Can the inspector tell me the keyboard height?
It exposes available viewport measurements, not a universal keyboard-size field. A change in visible height can include browser interface changes as well as the keyboard. Compare before and after states and use platform features according to their documented support. Avoid labelling every height difference as keyboard height.
What should a responsive bug report contain?
Include the browser, device or window setup, orientation, zoom method, viewport values and the exact action that causes the failure. State whether the keyboard was open and which field was focused. A cropped screenshot alone can hide the scale and scrolling context needed to reproduce the issue.