Fix Mobile Website Screenshots With a White Bar at the Bottom

A white bar at the bottom of a mobile website screenshot does not point to one universal CSS bug. First determine whether the strip belongs to the webpage, sits in a browser or safe-area region, or was introduced by the capture process. Then reproduce it on the affected phone and browser before changing the layout.

The device, browser, operating system, orientation, scroll position, and screenshot method are unknown here, so the cause cannot be diagnosed from the symptom alone. Historical WebKit reports document some mobile Safari viewport-height and nested-scroller problems, while Chrome documents Android edge-to-edge behavior; neither proves that every current phone has the same issue. WebKit report on iOS 15 nested scrolling · WebKit report on viewport height and browser controls · Chrome’s Android edge-to-edge guide.

1. Locate the white strip

Compare the screenshot with the live page on the same phone. Decide which region the strip occupies:

• Inside the document: the page may have extra content height, a section may end early, or a background may differ between elements.
• At the screen edge near browser controls: the visible viewport, browser chrome, or platform safe area may be involved.
• Only in a generated screenshot: inspect the capture viewport, full-page behavior, scroll position, and rendering timing.

Record the browser and version, OS version, portrait or landscape orientation, scroll position, whether the URL bar or toolbar is expanded, and how the screenshot was made. Check with browser controls expanded and collapsed, after scrolling, and after rotating. A desktop window resized to phone dimensions is not enough to reproduce device browser UI behavior.

2. Inspect full-height layout and scrolling

Search the page styles for height: 100vh, fixed-height sections, and nested scroll containers such as overflow: auto or overflow: scroll. If a non-body element owns scrolling, temporarily test the same content with document scrolling. Also compare a content-driven layout with the fixed-height version.

WebKit’s iOS 15 issue report described white space below a floating URL bar for a non-body scroll container with 100vh. The report records behavior changes and was closed as WONTFIX, so treat it as a documented failure mode to investigate, not a universal current Safari diagnosis. An older WebKit report also documents viewport-height content extending beyond the visible area and being obscured by browser controls. Nested-scroller report · Viewport-height report.

/* Diagnostic example: let content determine the page height. */
.page {
  min-height: 100vh;
  height: auto;
}

/* If the design needs a full visible-screen section, test modern viewport
   units on the target browsers rather than assuming 100vh matches the
   currently visible area. */
.hero {
  min-height: 100svh;
}

These are diagnostic alternatives, not drop-in fixes. Browser support and the desired behavior matter: a section that should track changing browser controls may need a different viewport unit from one that should remain stable. Verify on the affected device, with the controls in both states. Avoid replacing every 100vh blindly.

3. Check Android edge-to-edge and bottom UI

On Android Chrome, determine whether the page or a fixed bottom control extends into the gesture-navigation region. Chrome’s edge-to-edge guidance explains that content near the bottom can be obscured when the viewport extends into that area. The guide describes safe-area insets and cautions that padding tied to a dynamic bottom inset can cause layout thrashing as the browser chin moves. Follow the current platform guidance for the target behavior instead of copying a generic padding workaround. Chrome on Android edge-to-edge migration guide.

/* Example for content that must remain clear of a bottom safe area. */
.bottom-controls {
  padding-bottom: env(safe-area-inset-bottom, 0px);
}

Use this only when the target browser and layout call for safe-area accommodation. It is not a general white-bar fix: extra inset padding can itself look like blank space if its background is wrong or the content should not extend edge-to-edge.

4. Compare root backgrounds and safe-area styling

A strip can look white because the page’s main content has the intended color but the root, body, safe-area region, or browser chrome exposes a different background. This is especially worth checking on dark pages and gradients. Compare the computed backgrounds of html and body, inspect the area beyond the main content, and note the viewport configuration and theme color.

html,
body {
  margin: 0;
  min-height: 100%;
  background: #171717; /* replace with the page's intended background */
}

A developer’s iPhone Safari example identifies the root background, safe areas, viewport-fit=cover, and theme-color as variables to inspect; that is a diagnostic lead rather than official platform guidance. Do not add viewport-fit=cover or change theme metadata without confirming that the page should draw into those areas and checking the relevant browser behavior. Background and safe-area diagnostic example.

5. Verify the screenshot capture path

If the live page looks right but a captured image has the strip, compare like with like: viewport width and height, device scale, full-page versus viewport capture, scroll position, and whether the capture waited for the page to settle. A screenshot tool may capture a different viewport or a transitional layout than the one you inspected manually. Recreate the same dimensions and page state before attributing the result to CSS.

For an API capture, inspect the returned image and the response status or diagnostic headers the service documents. Do not infer a browser defect from one screenshot if the capture configuration differs from the affected phone.

6. Change one variable and retest

1. Keep a screenshot of the original symptom and note the reproduction steps.
2. Change one candidate cause: scrolling container, height rule, safe-area treatment, or background.
3. Repeat on the same device, browser, orientation, scroll position, and toolbar state.
4. Check a second relevant browser or OS version if the page must support it.
5. Keep the change only if it fixes the observed strip without hiding content or creating a new gap in another viewport state.

Common causes and fixes

What you observe	Likely area to inspect	Next step
Strip appears below a full-height section as browser controls move	100vh assumptions or nested scrolling	Compare document scrolling, content-driven height, and an appropriate viewport unit on the affected browser.
Bottom content is covered near Android gesture navigation	Edge-to-edge and safe-area behavior	Consult Chrome’s current guidance and test the bottom inset treatment on the target device.
Strip is white while the page is dark or gradient-filled	Root/body or safe-area background mismatch	Inspect computed backgrounds and browser theme configuration before changing metadata.
Only an automated screenshot has the strip	Capture viewport, page state, or timing	Match dimensions and scroll state; wait for layout and content to settle; compare with a same-device capture.
Fix works in one orientation but fails in another	Viewport dimensions or fixed bottom layout	Retest both orientations and avoid hard-coded heights where content can determine height.

Or skip the browser setup

To capture a page consistently without configuring a local browser, ScreenshotNeo provides a screenshot API and MCP server. One GET request returns an image or PDF; use the same target URL and relevant viewport options when comparing captures. The API parameters and setup are documented at ScreenshotNeo docs.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. These captures can help inspect the page, but compare against the actual phone when browser chrome or safe areas are the suspected cause.

Sign up for 1,000 free screenshots a month, with no card.

Troubleshooting

The strip remains after changing 100vh

Confirm that the affected element actually uses that rule and check for a parent with fixed height, margin, or overflow clipping. Reproduce with the browser toolbar in both states. If the strip is outside the document, a page-height change may not address it.

Safe-area padding makes the gap larger

Check whether the inset is being added to an element that already includes bottom spacing, and whether the region’s background matches the design. Follow platform-specific guidance; do not continuously update padding from a moving browser inset without considering the layout effect.

The screenshot differs from the live phone

Match the capture’s viewport dimensions, scale, page scroll, and full-page setting. Wait for fonts, images, and dynamic content to settle. If the mismatch aligns with browser controls, use a same-device screenshot to confirm whether the API image represents the same visible region.

It only happens in one browser version

Keep the report’s browser and OS versions with the reproduction. Historical WebKit issue reports establish that particular behaviors existed; they do not establish the cause on a different release. Test the suspected layout in the exact version before applying a browser-specific workaround.

Performance, reliability, and cost

For a local diagnosis, changing one CSS variable at a time is quick and avoids adding tooling to the page. Full-page captures and pages with lazy-loaded content can take longer than a viewport capture because more content may need to render. Repeated captures are useful for comparing states, but keep dimensions and page state consistent so the comparison is meaningful.

For recurring or automated captures, account for browser rendering variability, dynamic content, network delays, and third-party widgets. ScreenshotNeo bills only clean shots; its response includes X-Page-Verdict and X-Billed headers indicating the page verdict and billing status, and cache hits cost nothing. Plans are Free (1,000 shots/month), Starter ($5 for 3,000), Growth ($15 for 15,000), Pro ($39 for 60,000), Scale ($99 for 250,000), and Business ($249 for 1,000,000); yearly billing gives two months free. Every feature is on every plan. See the API documentation for capture options and response details.

FAQ

Is this always an iPhone Safari bug?

No. The strip may be webpage content, a safe-area or browser-control region, a background mismatch, or a capture artifact. The device and reproduction details determine which explanation fits.

Should I always use 100dvh?

No single viewport unit is a universal fix. Choose based on whether the section should track changing browser controls or remain stable, then verify on the browsers you support.

Can a screenshot API prove the page is correct on a phone?

No. An API capture can standardize image generation, but it does not reproduce every phone’s browser UI and safe-area behavior. Verify the affected layout on the actual device.

What details should I include in a bug report?

Include a screenshot, device and OS, browser version, orientation, scroll position, toolbar state, capture method, and whether the page uses full-height sections or a nested scroller.