How to Generate Website Screenshots at Mobile Sizes with a Screenshot API

To generate a website screenshot at a mobile size, send the page URL to a screenshot API and set the browser viewport to the CSS width you want to inspect. For a mobile-browser-like capture, also configure mobile viewport behavior, touch support, orientation, and device scale factor when the API supports them. A narrow output image alone does not guarantee that the page used a mobile responsive layout.

This guide shows how to choose those settings, capture a viewport or full page, and troubleshoot the result. The examples use ScreenshotOne and Browserless where their documented APIs are relevant; option names and availability vary by provider.

1. Choose what “mobile size” means for this capture

Decide whether you need a screenshot of the visible screen or the entire document. Then choose a CSS viewport width that matches the layout you want to inspect. Responsive breakpoints respond to the browser viewport width, not simply to the final image’s pixel width.

Goal	What to configure
Inspect the visible screen	Set viewport width and height to the CSS layout size and visible fold you need.
Inspect the whole page	Set the mobile viewport width, enable full-page capture, and account for lazy-loaded content and the provider’s full-page strategy.
Approximate mobile browser behavior	Set the viewport plus mobile viewport handling, touch, orientation, and device scale factor where available.
Reproduce a custom breakpoint	Set explicit CSS viewport dimensions rather than relying on a device name.

A 375-pixel-wide viewport is a documented example of a mobile layout width. Use the width relevant to your design or target device; do not assume a marketed screen resolution is the same as its CSS viewport width.

2. Viewport dimensions, emulation, and output pixels

Viewport width and height

Viewport width drives responsive layout: it can change navigation, columns, typography, and breakpoint-specific components. Viewport height controls the visible fold for a regular viewport capture. With full-page capture, providers may stretch the page or scroll and stitch sections, so height can work differently.

Device scale factor

Device scale factor (DPR) relates CSS pixels to rendered image pixels. A higher factor can produce a sharper, larger image; it can also increase rendering work and output size. Set it intentionally and inspect the returned image at its actual dimensions. If the API supports post-capture resizing, treat that as a separate output setting: resizing does not change which responsive layout the browser rendered.

Device profiles and mobile behavior

A named device profile may apply a bundle of viewport and emulation settings. Check the provider’s documentation, then override individual settings if the preset does not match your target. ScreenshotOne documents width, height, device scale factor, mobile viewport behavior, touch, landscape, and predefined device emulation; it states that device emulation is not performed on an actual device. Browserless documents viewport settings including mobile, touch, and landscape.

If you need mobile-browser behavior rather than only a narrow responsive layout, configure those properties deliberately. An API capture remains browser emulation, not proof of how a physical phone, browser version, or GPU will render the page.

3. Generate the screenshot with a screenshot API

For a quick integration, use the provider’s direct screenshot endpoint. Browserless documents a POST /screenshot endpoint that returns an image and accepts Puppeteer-style options, including viewport dimensions and device scale factor. Its viewport schema includes mobile, touch, and landscape settings. Check the provider’s current documentation for authentication, endpoint URL, and exact request schema before using this example in production.

curl -X POST "https://production-sfo.browserless.io/screenshot?token=$BROWSERLESS_TOKEN" \
  -H "Content-Type: application/json" \
  --output mobile.png \
  --data '{
    "url": "https://example.com",
    "options": {
      "type": "png",
      "fullPage": false
    },
    "viewport": {
      "width": 375,
      "height": 812,
      "deviceScaleFactor": 2,
      "isMobile": true,
      "hasTouch": true,
      "isLandscape": false
    }
  }'

Use the endpoint and authentication format from your Browserless account documentation. Keep the token in a server-side environment variable; do not put it in public frontend code.

What to change for a full-page capture

Enable the provider’s full-page option while keeping the mobile viewport width. The full-page strategy determines whether the service expands the page or scrolls through it. Scrolling can trigger lazy-loaded images and sections, but it adds work and may take longer. If the page loads content only after scrolling, use the provider’s documented scrolling or full-page controls and allow additional time.

4. Configure and request the capture reliably

Choose the target state. Identify the URL, any required authentication, and whether you need the initial viewport or full page.
Set the CSS viewport. Use explicit width and height for a reproducible layout. Use a device preset when its settings fit, and verify or override them.
Set emulation deliberately. Configure mobile viewport handling, touch, orientation, and device scale factor if supported and relevant.
Wait for the page you need. Use a selector wait, a short delay, or a network-idle condition if available. Dynamic content and client-side rendering may not be ready at navigation completion.
Handle lazy content. For full-page output, check whether the provider scrolls or captures sections. Allow the page to load content as it enters view.
Choose output separately. Select PNG, JPEG, or WebP and any output resize options supported by the service. These affect the returned file, not the browser’s responsive viewport.
Inspect the artifact. Check the page’s layout, image dimensions, and whether the intended content appeared. Treat the result as an emulated browser capture.

5. ScreenshotOne options for mobile captures

ScreenshotOne documents these settings for device and page capture. Consult its current documentation for accepted parameter names and combinations.

Setting	When to use it	What to verify
Width and height	Choose the CSS layout width and visible fold.	Width should match the breakpoint or target layout you intend to inspect.
Device scale factor	Control pixel density and output sharpness.	Higher values can increase image dimensions and rendering work.
Mobile viewport	Emulate mobile viewport behavior where needed.	A narrow capture by itself may not enable this behavior.
Touch support	Capture pages whose behavior depends on touch-capable input.	Touch emulation does not reproduce every physical-device interaction.
Landscape	Inspect a landscape mobile layout.	Set orientation intentionally; do not rely on a preset’s default.
Device profile	Apply a documented bundle of device settings.	Verify its values and override individual settings when needed. It is emulation, not a real device.
Full-page and scrolling controls	Capture content below the fold and trigger lazy loading.	Full-page algorithms vary; scrolling or section capture may add time.
Output format and resizing	Manage file compatibility and output dimensions.	These settings do not select the responsive layout; viewport width does.

ScreenshotOne’s full-page guide notes that rendering behavior varies by page, and that tuning can trade performance for rendering quality. Allow enough time for the content you need, but avoid waits and full-page work that do not contribute to the capture.

6. Security, performance, reliability, and cost

Keep credentials private

Use HTTPS and store API keys or tokens on a server or in a secrets manager. A key embedded in browser JavaScript or a public page can be copied and used by others. If users can submit arbitrary URLs to your capture service, validate and constrain requests according to your application’s security requirements.

Control rendering work

Use the smallest viewport and device scale factor that meet the image-quality requirement.
Capture only the viewport when you do not need the entire document.
Keep waits targeted: wait for the element or state that matters instead of adding a long fixed delay by default.
Use full-page scrolling when lazy-loaded content is required, knowing it can increase render time.
Choose the output format and image dimensions that fit the downstream use.

Make automation repeatable

Use the same viewport, emulation settings, URL state, and wait condition for captures you compare over time. Dynamic content, ads, animations, fonts, and network timing can still vary. Where supported, reduce motion or wait for a stable selector; do not assume that one successful render guarantees identical output on every run.

Screenshot API cost depends on the provider’s current pricing and billing rules. Compare how it counts failed navigations, retries, full-page work, and output options before estimating volume. Larger or longer captures can also consume more rendering time even when a provider bills per request.

7. Troubleshooting mobile screenshot problems

Symptom	Likely cause	Fix
The image is narrow, but the site still looks like desktop	The browser viewport width is not the intended CSS width, or mobile viewport behavior was not enabled.	Set the viewport width explicitly and check the provider’s mobile viewport option. Confirm the page’s responsive breakpoints.
Text or assets look soft or too large	Device scale factor or output resizing is not what you expected.	Inspect DPR and the final image dimensions. Adjust capture scale and output resizing independently.
Content below the fold is missing	Full-page capture is off, or lazy content did not load.	Enable full-page mode and use the documented scroll or section strategy. Wait for the content to appear.
The capture is slow	Large viewport, high scale factor, full-page scrolling, or excessive waits add rendering work.	Reduce unnecessary dimensions, capture only what you need, and wait for a specific page state.
The output differs between runs	Dynamic content, animation, font loading, or network timing changed the page state.	Use a consistent URL and wait condition; reduce motion or wait for stable content where supported.
A device preset does not match the target	The preset applies a bundle of values that differ from the desired viewport or emulation.	Check the preset’s documented settings and override width, height, scale, touch, or orientation as needed.
The capture does not match a physical phone	Device profiles emulate browser characteristics; they do not run on the actual phone.	Use the screenshot for responsive inspection, then test hardware-specific behavior on a real device.
Authentication fails or the API key is exposed	Credentials are missing, malformed, expired, or placed in public code.	Follow the provider’s current HTTPS authentication instructions and move secrets to server-side configuration.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. One GET request accepts a URL and returns a PNG, JPEG, WebP, or PDF. It supports viewport dimensions, device presets, and full-page capture with lazy images loaded. See the ScreenshotNeo API documentation for request options.

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

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers say which page verdict and billing outcome applied. AI agents can use its MCP server tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

9. Frequently asked questions

Does a mobile-size screenshot prove that a page works on a phone?

No. It shows an emulated browser capture at the configured viewport and device settings. Test on physical devices for hardware- or browser-specific behavior.

Should I use a device name or set dimensions myself?

Use a profile when its documented settings match the behavior you need. Set dimensions and emulation properties explicitly when you need a particular breakpoint or reproducible custom viewport.

Does a higher device scale factor change the responsive breakpoint?

The CSS viewport width selects the responsive layout. Device scale factor affects rendered pixel density and image dimensions.

Why can a full-page mobile capture take longer?

The service may need to scroll through sections, trigger lazy-loaded content, and render more of the document. The exact work depends on the provider’s full-page strategy and the page itself.