How to test a website screenshot on iPhone and Android devices with LambdaTest

To capture a website screenshot on an iPhone or Android device with LambdaTest, sign in to TestMu AI (the platform formerly called LambdaTest), open Real Time Testing > Browser Testing, choose a mobile platform and available device/browser environment, start the session, and load your URL. Use the session’s screenshot control to capture the page; you can annotate and download the image, and retrieve captures later from the Gallery or test logs.

Important availability note: TestMu AI’s guide says real-device website testing is in beta and access may require contacting support. Your account may not show the feature or every device/browser combination described here.

1. Choose the right mobile test path

TestMu AI documents two relevant workflows. Choose based on whether you need a one-off visual inspection or a repeatable scripted check:

Path	Use it for	What to know
Real Time Testing > Browser Testing	Manually opening a mobile browser, inspecting a page, and capturing an image for a bug report.	The real-device web workflow is beta and may require support to enable it.
Appium mobile web automation	Repeatable scripted checks on real devices.	The documented guide names Chrome on Android and Safari on iOS for this automation path. Check the current support matrix before relying on a specific combination.
Virtual mobile session	Checking a configuration using a simulated mobile environment.	The FAQ describes virtual mobile sessions as Android emulators and iOS simulators. A virtual session is not a physical phone.
Real Device Cloud	Validating on a physical phone or tablet.	Use this route when physical hardware is required; device inventory and account entitlements can vary.

The manual workflow below is for a live browser session. It does not require writing a test script.

2. Capture a website screenshot in a live mobile browser

Sign in to your TestMu AI account.
From the left navigation, open Real Time Testing, then Browser Testing.
Choose Android or iOS. Select from the brand, device/OS, and browser options available in your account.
Start the session and navigate to the website. For a page behind authentication, sign in using the browser session as you would on the device.
When the page is ready, use the session’s screenshot camera control. The image editor opens so you can annotate the capture and add bug details.
Download the screenshot, or submit it with an issue through an available integration. Captures may also be retrieved from the Gallery or test logs.

Interface labels can change. The key outcome is to capture the rendered page, annotate it if needed, and save or retrieve the resulting image.

3. Make the screenshot useful for debugging

Record the environment: note the selected device, operating system, browser, and session details with the bug. A screenshot without its environment can be hard to reproduce.
Capture the relevant state: wait for the page to finish rendering, then reproduce the issue before taking the image. Include the navigation, dialog, or control that provides context.
Annotate precisely: mark the affected area and describe the expected result in the issue details. Keep the original capture available when possible.
Check responsive behavior: compare the iPhone and Android results at the relevant viewport and browser, rather than assuming the same layout means the same behavior.
Separate virtual and physical evidence: label emulator/simulator captures as virtual and Real Device Cloud captures as physical-device results.

A screenshot is a visual record, not a full interaction test. If the bug depends on taps, navigation, or a browser-specific behavior, preserve the session context or add an automated check.

4. Automate repeatable mobile web checks with Appium

For regression checks, TestMu AI documents a separate Appium workflow on real iOS and Android devices. Its mobile web automation guide identifies Chrome on Android and Safari on iOS and uses the isRealMobile capability. The exact endpoint, credentials, and capabilities depend on the current TestMu AI Appium documentation and account configuration; use that guide’s complete sample for a runnable test rather than copying an outdated endpoint into a project.

Keep automation separate from the manual screenshot path: a successful Appium run can verify repeatable steps, while the live Browser Testing workflow is useful for inspecting and annotating a one-off visual defect. Confirm the current device/browser matrix before adding a combination to CI.

5. Troubleshooting

Symptom	Likely cause	What to do
Browser Testing or real-device web testing is missing.	The real-device web feature is beta and may not be enabled for the account.	Contact TestMu AI support to ask about access. Confirm that you are in Real Time Testing and looking under Browser Testing.
The desired phone, OS, or browser is not selectable.	That combination may not be available to the account or in the selected workflow.	Check the available environment choices and current support matrix. Do not assume the manual and Appium workflows expose identical combinations.
The session is virtual, but the bug only occurs on a physical device.	Virtual mobile sessions use emulators or simulators.	Use Real Device Cloud for physical-device validation, if available to your account.
The screenshot shows a loading state or incomplete page.	The page had not reached the state you intended to capture, or content loads after navigation.	Wait for the page and relevant content to render, reproduce the target state, then capture again. For a repeatable check, encode the required wait in the automated test.
You cannot find a screenshot after closing the session.	The capture may be stored with the session rather than in the current view.	Look in the Gallery or test logs and download the capture from there.
An Appium browser check does not launch on the selected platform.	The selected browser/device may not be supported by that automation workflow, or capabilities may be incorrect.	Verify the current Appium guide’s platform/browser support, real-device capability, and account configuration.

6. Performance, reliability, and cost considerations

Cloud mobile sessions depend on the selected environment, page load, and network conditions. For comparable screenshots, keep the URL, device/browser selection, page state, and timing consistent. If a page uses delayed images or asynchronous content, capture only after the relevant content is visible. For recurring checks, automation can make the steps repeatable, but it does not remove the need to select a supported environment.

The cited TestMu AI documentation does not establish current pricing, account entitlements, device inventory, or session limits. Check your account and the current product terms for those details. The beta qualification also means access should be confirmed before making this workflow a release dependency.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A single request captures a URL as PNG, JPEG, WebP, or PDF. Its API can capture a public page without setting up a mobile browser session; it does not replace testing on a physical iPhone or Android device when device-specific behavior is what you need to validate.

See the ScreenshotNeo API documentation for options and response details. This cURL example saves a screenshot:

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

Equivalent Python:

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()
open("shot.webp", "wb").write(r.content)

Equivalent 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 import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed; response headers identify the page verdict and billing result. An MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month with no card.

Frequently asked questions

Is LambdaTest still the product name?

The documentation referenced here is branded TestMu AI and describes it as formerly LambdaTest. The title uses LambdaTest because that is the name many developers search for.

Can I use a virtual iPhone session to prove a bug on a real iPhone?

No. The FAQ distinguishes iOS simulators from physical devices. Use a physical-device workflow when the issue depends on actual hardware or browser behavior.

Does a saved screenshot prove the page works on every mobile browser?

No. It records one rendered state in one selected environment. Test each browser/device combination relevant to your users.

Can ScreenshotNeo validate touch behavior on an iPhone?

A screenshot API returns an image of a URL; it is not a substitute for interacting with a physical mobile browser when the behavior under test depends on device interaction.

Sources

TestMu AI: Web Testing on Real Devices — manual workflow, screenshot annotation/download, Gallery, and beta access qualification.
TestMu AI: Mobile Web Automation Testing on Real Devices — Appium workflow and documented browser support.
TestMu AI FAQ — screenshot control and virtual versus physical mobile sessions.