Keyword: responsive screenshot API ยท Updated July 31, 2026

Responsive Screenshot API: Capture Mobile, Tablet, and Desktop QA Evidence

Responsive bugs rarely announce themselves in logs. A navigation wraps over a sign-in link, a sticky banner hides the checkout button on mobile, or dark mode ships with unreadable contrast. A responsive screenshot API gives product, QA, and support teams a repeatable way to capture those viewport-specific states without opening DevTools by hand.

Why this is timely

Browser-tooling teams are pushing responsive verification into automated and agent-assisted workflows. Chrome's May 2026 DevTools for agents guidance explicitly highlights viewport, user-agent, geolocation, network, CPU, and color-scheme emulation for checking user experiences. Playwright's current release notes also keep moving visual workflows forward, including WebP screenshots for visual comparisons and bundled MCP tooling.

The underlying web need is not new: MDN and Google both continue to frame responsive layout and mobile-first behavior as core web requirements. What changed is the workflow. Teams increasingly want evidence that can be attached to a ticket, stored in a review system, or fetched by an automation agent. SnapshotFlow fits the capture side of that workflow: it renders in Chromium and exposes viewport, mobile emulation, retina, dark mode, reduced motion, media type, timezone, geolocation, user agent, wait, click, selector, and response-format controls through one HTTP API.

Scope: this guide is for repeatable responsive evidence capture. For pixel-to-pixel regression assertions, use the visual regression guide. For country or city localization, use the geo-targeted screenshot guide.

What a responsive capture set should include

Pick breakpoints from your product, not from a generic device list. Most teams only need a small review set that maps to real decisions: phone, tablet or narrow desktop, production desktop, and one preference variant such as dark mode.

CaptureSnapshotFlow parametersWhy it matters
Mobile portraitwidth=390, height=844, viewport_mobile=true, device_scale_factor=3Checks compact navigation, sticky footers, tap-sized controls, and high-density image output.
Tablet or narrow desktopwidth=768, height=1024, device_scale_factor=2Catches awkward mid-width layouts that are missed by phone-plus-desktop reviews.
Desktopwidth=1440, height=900, device_scale_factor=1Provides the baseline evidence most stakeholders expect in a product review.
Dark modedark_mode=trueEmulates prefers-color-scheme: dark for pages that honor user color preferences.
Reduced motionreduced_motion=trueEmulates prefers-reduced-motion: reduce when animations could affect capture stability or accessibility review.

1. Capture a mobile screenshot with cURL

Use GET /screenshot when each viewport needs the full capture option set. This example returns a hosted URL for storage or ticket attachment. Use response_type=base64 when your next step needs inline image data instead.

curl --get "https://api.snapshotflow.com/screenshot" \ -H "X-Api-Key: $SNAPSHOTFLOW_API_KEY" \ --data-urlencode "url=https://example.com/pricing" \ --data-urlencode "response_type=url" \ --data-urlencode "format=webp" \ --data-urlencode "quality=82" \ --data-urlencode "width=390" \ --data-urlencode "height=844" \ --data-urlencode "device_scale_factor=3" \ --data-urlencode "viewport_mobile=true" \ --data-urlencode "wait_until=networkidle2" \ --data-urlencode "wait_for_selector=main" \ --data-urlencode "block_ads=true" \ --data-urlencode "block_cookie_banners=true"

Expected behavior: SnapshotFlow validates the target URL, renders it in Chromium with a 390 by 844 mobile viewport, enables touch/mobile viewport behavior, waits for the page and main selector, captures WebP output, saves it, and returns a plain-text download URL. If wait_for_selector or click does not match an element, the API returns a SELECTOR_NOT_FOUND error instead of a misleading screenshot.

2. Capture a breakpoint set with the Node SDK

The official Node SDK is a thin wrapper over the HTTP API. It uses camelCase options and converts them to SnapshotFlow's snake_case query parameters. This loop creates three reviewable URLs from the same page.

import { SnapshotFlow } from "snapshotflow"; const client = new SnapshotFlow({ apiKey: process.env.SNAPSHOTFLOW_API_KEY, }); const target = "https://example.com/pricing"; const breakpoints = [ { name: "mobile", width: 390, height: 844, deviceScaleFactor: 3, viewportMobile: true }, { name: "tablet", width: 768, height: 1024, deviceScaleFactor: 2 }, { name: "desktop", width: 1440, height: 900, deviceScaleFactor: 1 }, ]; for (const bp of breakpoints) { const url = await client.takeUrl({ url: target, responseType: "url", format: "webp", quality: 82, waitUntil: "networkidle2", waitForSelector: "main", blockAds: true, blockCookieBanners: true, ...bp, }); console.log(`${bp.name}: ${url}`); }

Add dark-mode evidence

Dark mode is a separate state, not a replacement for mobile or desktop evidence. Capture it explicitly when your CSS uses prefers-color-scheme.

const darkDesktop = await client.takeUrl({ url: target, responseType: "url", width: 1440, height: 900, darkMode: true, waitUntil: "networkidle2", waitForSelector: "main", });

Operational advice and edge cases

  • Do not pretend this is Safari or a physical iPhone. SnapshotFlow renders with Chromium/Puppeteer. Viewport and mobile emulation are useful for layout evidence, but they do not prove WebKit, iOS, Android WebView, camera, sensor, or operating-system behavior.
  • Keep waits deterministic. Prefer wait_for_selector for the main app shell or loaded state. Use delay sparingly and keep it below the API limit of 10 seconds.
  • Use cache=false for investigation runs. Cached captures are useful for repeated reads. Disable cache when you are verifying a live fix or comparing before/after deploys.
  • Use single-page captures for full emulation control. SnapshotFlow's batch endpoint is useful for many URLs with shared basic settings, but responsive breakpoint sets often need per-request mobile, dark-mode, user-agent, or geolocation parameters.
  • Capture the visible viewport unless the task needs a long page. full_page=true is useful for complete content reviews, but viewport screenshots better reflect what a user sees without scrolling.
  • Hide noisy UI only when it is not the subject of the review. block_ads, block_cookie_banners, hide_selectors, and click can clean captures, but note those choices in the ticket so reviewers know what state was captured.
  • Store enough metadata next to the image. Save the URL, width, height, device scale factor, mobile flag, dark-mode flag, wait condition, and capture time. The screenshot is much easier to trust when the environment is visible.
Security note: use cookies, headers, and authenticated captures only for pages you are authorized to access. Keep API keys and session cookies server-side; do not paste them into public tickets or client-side scripts.

FAQ

Can this replace real-device QA?

No. It replaces a lot of repetitive viewport screenshot collection, not final device coverage. Keep real devices or platform-specific browser testing for WebKit/iOS, Android WebView, native inputs, sensors, and device-only bugs.

Should the output be PNG, JPEG, or WebP?

Use PNG for exact UI evidence, WebP when review storage size matters, and JPEG for photographic pages where small compression artifacts are acceptable. SnapshotFlow supports all three image formats and PDF on the same endpoint.

Can I compare responsive captures automatically?

Yes, but treat that as a visual regression workflow. SnapshotFlow's visual regression guide covers /diff, baselines, thresholds, and CI behavior in more detail.

Sources and further reading

Build the capture set once

Start with the SnapshotFlow Playground to tune one viewport, then move the same parameters into cURL, the Node.js SDK, or your QA workflow.

Start free