How to fix a responsive screenshot that is too wide on mobile

A mobile screenshot that looks too wide usually has one of two causes: the page was captured at the wrong CSS viewport width, or an element in the page is wider than its container and causes horizontal overflow. Check the screenshot’s CSS viewport, verify the viewport meta tag, reproduce at the same width, and inspect the element forcing the page wide. Fix the layout at its source, then capture again at the same viewport.

1. First distinguish viewport size from screenshot size

A screenshot’s bitmap dimensions are not necessarily the page’s layout dimensions. The browser lays out a page in CSS pixels; device pixel ratio can make the resulting image contain more physical pixels than CSS pixels. A full-page capture can also be taller than the visible browser viewport. Neither condition alone means the page is too wide.

Record the capture’s CSS viewport width and height, device pixel ratio if available, and whether it was a viewport or full-page screenshot. Compare the CSS viewport width with the intended phone layout. Do not use the image’s pixel width as a substitute for the CSS viewport width.

What you see	Likely explanation	Next check
The whole page resembles a scaled-down desktop layout	The browser may be laying out the page in a wide virtual viewport.	Check the viewport meta tag and capture width.
The page is laid out for mobile, but content sticks out sideways	An element or layout constraint is causing horizontal overflow.	Find the widest element and inspect its computed width.
The screenshot file has more pixels than the configured viewport	Device pixel ratio, image scaling, or full-page capture may explain the dimensions.	Compare CSS viewport dimensions and capture settings.

2. Check the viewport meta tag

Inspect the document’s <head> for a viewport declaration. A common mobile declaration is:

<meta name="viewport" content="width=device-width" />

Without a viewport tag, some mobile browsers may use a wide virtual layout viewport—typically 980 CSS pixels—and scale the result down. That can make a page look like a shrunken desktop site and prevent the expected mobile breakpoints from behaving as intended. MDN describes the viewport tag and this wide-viewport behavior in its CSS viewport guide.

Put the tag in the document head and make sure the page actually serves it. Check the rendered document if a template, framework, or server-side layout controls the head. initial-scale=1 is commonly included, but MDN notes it may be unnecessary. The essential first check is that the layout viewport uses the device width; do not use zoom behavior to conceal overflowing content.

<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width" />
  <title>Responsive page</title>
</head>

3. Reproduce the capture at its CSS viewport width

Open the page in Chrome and open DevTools.
Turn on Device Mode and choose Responsive.
Set the viewport width and height to the values used for the screenshot, in CSS pixels.
Show media query breakpoints and note which breakpoint is active.
Compare the page with the screenshot, then capture a new screenshot at the same dimensions after each fix.

Chrome’s Device Mode guide covers responsive dimensions, breakpoints, and screenshot capture. Emulation is useful for reproducing layout, but it cannot simulate every behavior of a real mobile device. If the emulated result conflicts with the reported screenshot, verify on the actual phone too.

4. Find what is forcing the page wider

Once the viewport is correct, locate the element whose rendered width exceeds the viewport or its intended parent. In DevTools, inspect likely elements and their computed width, minimum width, margins, padding, and positioning. Temporarily outline elements or hide a suspected element in DevTools to see whether the horizontal overflow disappears; use this only to identify the cause, not as the final repair.

Fixed-width wrappers: a container with a fixed pixel width may be wider than a phone viewport. Check nested wrappers as well as the page’s main container.
Images and media: an image with an intrinsic or explicit width can exceed its parent. Check the rendered dimensions and the CSS that controls sizing.
Long unbroken content: URLs, identifiers, code, or other strings without break opportunities can force a column wide.
Tables: wide tables may need a deliberate narrow-screen presentation or a locally scrollable wrapper.
Flex and grid children: a child’s intrinsic minimum size can prevent a column from shrinking. Inspect the child and its parent sizing rules.
Navigation: a desktop navigation row may not wrap or collapse at the narrow width.
Positioned elements: absolutely positioned content, translated elements, or oversized decorative elements can extend beyond the viewport.

These are diagnostic possibilities, not a claim that any one element is present on your page. Check the actual rendered page and change the constraint that produces the excess width.

5. Fix the layout at its source

Prefer fluid sizing and constraints that let content fit its container. For example, a page can use a flexible wrapper and images can scale down within their parent:

* {
  box-sizing: border-box;
}

.page {
  width: min(100% - 2rem, 72rem);
  margin-inline: auto;
}

img,
video,
canvas,
svg {
  max-width: 100%;
}

img,
video {
  height: auto;
}

This is a starting point, not a universal stylesheet. Check components with fixed widths, minimum widths, or special intrinsic sizing individually. For a long unbroken string, choose a wrapping policy appropriate to the content, such as overflow-wrap: anywhere for text that may safely break. For a data table, preserve its legibility with a horizontally scrollable table region or a purpose-built narrow-screen layout rather than shrinking columns until the data is unusable.

Use media queries when the content needs a layout change at a particular width—for example, changing a multi-column layout to one column or replacing a wide navigation arrangement. Media queries are useful but not required for every responsive layout; flexible sizing can adapt without a breakpoint. Choose breakpoints based on where the content stops fitting, then test just below and above them.

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1rem;
}

@media (max-width: 40rem) {
  .site-nav {
    /* Apply the narrow-screen navigation pattern used by this site. */
  }
}

Avoid making overflow-x: hidden on the whole page the only fix. It can hide the scrollbar while clipping controls, text, or other content that still does not fit. Use horizontal overflow intentionally on a specific component only when that is the right interaction, such as a wide table.

MDN’s responsive design guide explains fixed-width overflow and responsive techniques including flexible layouts and media queries.

6. Verify the correction

Reload at the original CSS viewport width and confirm the intended mobile layout appears.
Check for horizontal scrolling and clipped content, not just whether the screenshot looks narrower.
Test widths just below and above each relevant breakpoint.
Check a taller page and important states such as open navigation, expanded content, and long text.
Capture again using the same viewport, device scale, and viewport-versus-full-page setting as the original comparison.
Verify on a real phone if device emulation and the reported result differ.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Make one GET request for a screenshot; see the ScreenshotNeo API documentation for request options. For a repeatable mobile capture, set the viewport options supported by the API and compare captures at the same CSS viewport size.

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

import requests

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

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

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the capture; each step can be turned off. Bot checks, blank pages, timeouts, and failed loads are not billed, and cache hits cost nothing. Its response identifies the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Learn about ScreenshotNeo or sign up free for 1,000 screenshots a month with no card.

Troubleshooting

Symptom	Likely cause	What to do
Mobile capture shows a small desktop layout	Missing or ineffective viewport declaration, or capture made at a desktop CSS width.	Verify the rendered viewport tag and the capture’s CSS viewport dimensions.
It fits in DevTools but not on the phone	Emulation does not reproduce every device behavior, or the tested width/state differs.	Check on the device and compare viewport, browser, page state, and orientation.
Scrollbar disappears but content is cut off	Overflow was hidden without correcting the oversized element.	Find the element imposing width and fix its sizing or wrapping.
One image or embed sticks out	Intrinsic dimensions or fixed CSS dimensions exceed the parent.	Constrain its maximum width and check its parent and aspect-ratio behavior.
A grid or flex row refuses to shrink	A child’s minimum or intrinsic size is larger than the available track.	Inspect minimum sizing and adjust the child or track so it can fit; retain intentional scrolling only where suitable.
Only long URLs or labels cause overflow	The content has no permitted wrap point.	Set a wrapping rule appropriate to that content and verify it remains readable.
The screenshot is wider than the device width in pixels	CSS pixels and bitmap pixels differ because of device scale, or the capture settings differ.	Compare CSS viewport dimensions, device pixel ratio, and capture mode.
A breakpoint appears not to run	The page’s layout viewport may not be the width you expect, or the breakpoint condition is wrong.	Verify the viewport tag, active media query, and CSS viewport width in DevTools.

Performance, reliability, and cost notes

For local debugging, reproduce at the target width and inspect only the elements that can explain the excess width; repeatedly capturing inconsistent viewport sizes makes comparisons less useful. Keep viewport width, height, device scale, page state, and capture mode consistent when comparing before and after.

For automated captures, a successful image response is not by itself proof that the page rendered in the intended responsive layout. Verify the requested viewport and inspect the output. ScreenshotNeo identifies page verdict and billing status in response headers; its stated billing rules exclude bot checks, blank pages, timeouts, failed loads, and cache hits. Its 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; Business, $249 for 1,000,000. Yearly billing gives two months free, and every feature is available on every plan. See the documentation for configuration details.

FAQ

Why is my website wider than my phone screen?

Either the browser is using a wider layout viewport than intended, or content in the page exceeds the available width. Check the viewport declaration first, then inspect the rendered elements.

Why does my mobile screenshot show the desktop layout?

Confirm the capture’s CSS viewport width and the document’s viewport meta tag. A wide virtual viewport can cause a scaled-down desktop-like layout, and a capture made at desktop width will not trigger narrow-screen styles.

Should I always add `initial-scale=1`?

It is commonly used, but the viewport-width declaration is the key check for this problem. Follow the behavior your page needs and verify on target browsers; do not depend on initial zoom to fix overflow.

Is hiding horizontal overflow a valid fix?

Only when clipping is intentional and safe for that component. For page-level overflow, find and correct the width constraint so users can reach all content.