How to capture a mobile website screenshot in BrowserStack
Use BrowserStack Live to inspect a site on a mobile device, or Responsive Testing to capture emulated viewport screenshots. Here is what each workflow can and cannot confirm.
To inspect a mobile website on a hosted real device, start a BrowserStack Live session, choose a mobile operating system, device, and browser, then open the website URL. If you need saved screenshots at several viewport sizes, use BrowserStack Responsive Testing: its documentation describes a camera control for one device view and a control to capture all device views. BrowserStack’s Live website-testing documentation describes issue reporting, but the page reviewed does not establish a general-purpose screenshot download control for a mobile website session.
Choose the workflow based on what you need to verify: Live is for viewing the site in a selected real-device browser; Responsive Testing is for capturing emulated responsive layouts. App Live is a separate mobile-app workflow and should not be confused with website testing.
1. Choose the right BrowserStack workflow
| Goal | Workflow | What the documentation confirms |
|---|---|---|
| Inspect a website in a mobile browser on a selected real device | BrowserStack Live | Choose the mobile OS, device, and browser, then open the site. The reviewed Live website documentation does not specify a general screenshot export. |
| Capture a site’s appearance at multiple screen sizes | Responsive Testing | Use the camera icon on a device view for an individual screenshot or the top-menu camera icon for all devices. |
| Capture a mobile app screen | App Live | This is for app sessions. Its documentation says Capture Screenshot downloads a PNG to the system Downloads folder. |
Use Live when behavior in a particular device and browser is central. Use Responsive Testing when you need a set of viewport captures. A responsive emulation is not evidence that every aspect of a physical device behaves the same way.
2. Inspect a mobile website in BrowserStack Live
- Sign in to BrowserStack and open Live website testing.
- Select the mobile operating system, device, and browser you want to inspect.
- Start the session and navigate to the target website.
- Reproduce the page state you want to review. This may include opening a menu, scrolling, dismissing a banner, or navigating to a specific route.
- Use the Live testing controls that are available in the session. The documented website toolbar includes Capture a Bug for reporting issues through integrations such as Jira, Trello, GitHub, and Slack.
- If you need an image file, check the current Live interface for an explicitly labeled screenshot or export control. The reviewed documentation does not confirm a general-purpose download button, its output format, or its save location for a mobile website session.
Do not assume the App Live screenshot behavior applies here: the App Live documentation describes a PNG saved in Downloads for a mobile app session, not for a website opened in Live.
3. Capture responsive viewport screenshots
- Open BrowserStack Responsive Testing and enter the page you want to review.
- Choose the device views or screen sizes relevant to your layout.
- To capture one view, use that device’s camera icon.
- To capture all displayed device views, use the camera icon in the top menu.
- Review the resulting screenshots and identify which viewport has the layout issue.
- If you need real-device validation, the Responsive Testing documentation also describes linking an emulated device to a real-device Live session.
This workflow is useful for comparing layout across sizes. For a real mobile browser rendering, open the page in a Live session as well.
4. Website screenshots versus app screenshots
BrowserStack documents a direct screenshot-download action in App Live: its toolbar’s Capture Screenshot control downloads a PNG to the system Downloads folder. That instruction is specifically for mobile app sessions. For a mobile website, use Live to inspect the site and rely on the controls the current website-testing interface actually provides; the reviewed Live website documentation establishes Capture a Bug for issue reporting, not a general screenshot-file export.
When describing or documenting a capture, record which workflow produced it, the selected device or viewport, browser, URL, and page state. That context prevents an emulated responsive capture, real-device website session, and app capture from being mistaken for one another.
5. Troubleshooting
| Problem | Likely cause | What to do |
|---|---|---|
| You cannot find a screenshot download control in Live | The reviewed Live website documentation does not specify a general-purpose screenshot export. App Live’s documented Capture Screenshot action is for app sessions. | Check the controls in the current Live interface and use only a clearly available export action. For documented viewport screenshots, use Responsive Testing’s camera controls. |
| You expected a PNG in Downloads after a website session | The Downloads-folder PNG instruction applies to App Live, not the documented Live website flow. | Confirm you are in an app session before following App Live instructions. For websites, use Responsive Testing captures or a confirmed website-session export control. |
| The page looks different from a physical phone you have | You may be comparing responsive emulation with a real-device browser session, or the sessions may differ in browser, viewport, or page state. | Compare the same URL, browser, viewport where possible, and interaction state; use Live when you need the selected real-device browser. |
| The screenshot misses a menu, dialog, or post-load content | The capture was made before the page reached the desired state. | Reproduce the interaction and wait for the relevant content before capturing. Note the state in your issue report. |
| You cannot capture all device views at once | You may be using a workflow or interface where the documented all-device camera control is not available. | Use Responsive Testing and its top-menu camera control, or capture individual device views using their camera icons. |
6. Reliability, workflow, and cost considerations
Hosted browser sessions avoid needing to own each device for the documented Live and Responsive Testing workflows. The choice still affects what the screenshot tells you: a Responsive Testing capture shows an emulated layout, while Live lets you inspect the selected device and browser. For repeatable review, keep the URL, device/browser choice, viewport, and page state consistent.
The research sources establish the workflows and screenshot controls described above, but do not establish BrowserStack plan prices, screenshot-specific charges, throughput, or retention. Check BrowserStack’s current product and account information for those details before planning a recurring capture workflow.
7. Automate website screenshots with an API
If your goal is a saved image of a website rather than interactive device testing, a screenshot API can avoid setting up and operating browser sessions. ScreenshotNeo is a website screenshot API and MCP server. Its one-request API returns a screenshot or PDF, and it accepts common screenshot API parameter names to ease migration. See the ScreenshotNeo API documentation for request options.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webpPython
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as f:
f.write(r.content)Node.js
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}`);
await Bun.write('shot.webp', res);The Node.js example uses Bun’s file writer. In Node.js without Bun, save the response with the built-in filesystem module:
import { writeFile } from 'node:fs/promises';
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}`);
await writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));Or skip the browser setup
Make one GET request to capture a page. Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers indicate the page verdict and billing status. An MCP server lets AI agents use the take_screenshot, get_page_info, and capture_pdf tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webpCreate a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.
8. Frequently asked questions
Can BrowserStack capture a mobile website on a real device?
Live lets you choose a mobile operating system, device, and browser, then open the website. The reviewed documentation does not confirm a general screenshot download control for that website session.
Can Responsive Testing capture more than one device view?
Yes. Its documentation describes a per-device camera icon and a top-menu camera control for screenshots of all devices.
Where does BrowserStack save a website screenshot?
The reviewed Live website documentation does not specify a general website screenshot download or save location. App Live documents a PNG saved in Downloads, specifically for app sessions.
Do I need to connect a physical phone?
No physical item is necessary for the documented hosted Live and Responsive Testing workflows.
When should I use an API instead of BrowserStack?
Use a screenshot API when you need to request website image or PDF captures programmatically. Use BrowserStack Live when you need to interactively inspect a selected device and browser.
