LambdaTest Screenshot Not Loading a URL: Troubleshooting Steps
Diagnose LambdaTest screenshot failures by checking the request, network access, login flow, and page rendering—in that order.
If LambdaTest Screenshot Testing does not load a URL, first identify which stage is failing: the request, the cloud browser’s access to the page, a login flow, or rendering after navigation. A successful request does not guarantee that the page’s scripts, images, and other assets have finished rendering when the screenshot is captured.
For API-based Screenshot Testing, check that the request contains a valid URL and uses the required Basic authentication. If the site is local or private, configure LambdaTest’s tunnel support. For a protected page, use the documented login workflow and verify its field locators. Treat wait and rendering settings documented for SmartUI as SmartUI settings; the available references do not establish that they also apply to the separate Screenshot Testing dashboard.
1. Identify what “not loading” means
Separate an API or access error from a screenshot that exists but looks blank, stale, or incomplete. The first calls for checking the request and reachability. The second points toward login state, page behavior, or asset rendering. This distinction is a diagnostic starting point, not a guaranteed explanation for any particular dashboard message.
| What you see | First checks |
|---|---|
| The API request returns an error | URL, request fields, Basic authentication, and the response body or status. |
| The test runs but the page is unavailable | Public reachability, private-network tunnel configuration, redirects, and login flow. |
| The screenshot is blank or partial | Whether navigation reached the intended page, whether content needs more time, and whether assets come from other hosts. |
2. Check the URL and API request
In LambdaTest’s API-based Screenshot Testing workflow, a start-test request includes a url value and uses Basic authentication. Inspect the submitted URL rather than relying on what opens in your local browser:
- Check spelling, the scheme (
https://orhttp://), hostname, and path. - Check whether the address redirects to a different hostname or to a login page.
- Confirm the request body is formatted as the API expects and includes the URL.
- Check the response and its status. The official start-test reference includes 400, 401, and 403 response examples. These indicate that request or access handling deserves investigation; they do not each prove one specific cause.
Keep the exact URL and response details for follow-up, but redact credentials, session tokens, and other secrets before sharing them.
3. Confirm that LambdaTest can reach the page
A remote cloud browser cannot automatically reach a page that exists only on your laptop, behind a VPN, or on a private network. Your local browser opening localhost proves local access, not cloud access. LambdaTest documents tunnel support for locally hosted pages; its start-test API reference includes optional tunnel and tunnel_identifier fields.
- Decide whether the tested hostname is public or private.
- For a private or locally hosted page, follow LambdaTest’s tunnel setup and ensure the tunnel is running when the screenshot test starts.
- If you use a tunnel identifier, make sure the test request refers to the matching tunnel setup.
- Check that redirects and page assets also resolve through the configured route.
Do not diagnose a private URL as a rendering delay until cloud reachability has been addressed. The API reference and LambdaTest’s local-page guidance are the relevant sources for this branch.
4. Set up login-protected pages deliberately
For pages behind a login, LambdaTest documents an authenticated screenshot workflow that starts at a login URL and identifies the username field, password field, and submit control. A wrong locator can prevent the workflow from reaching the intended destination page.
- Set the login URL, not a destination URL that requires an existing session.
- Verify that the username and password locators match the actual form controls.
- Verify that the submit-button locator selects the control that submits the form.
- Check that a successful submission reaches the expected page, including any redirect or second authentication step.
Use the authentication workflow documented for the LambdaTest feature you are using. Do not assume that API Basic authentication and website form login are interchangeable: API authentication authorizes the request, while the login flow supplies credentials to the page.
5. Diagnose blank or incomplete rendering
If the request succeeds and navigation appears to happen, check whether the content was ready at capture time. Pages that rely on JavaScript, asynchronous requests, lazy-loaded images, or asset hosts outside the main domain can render incompletely.
LambdaTest’s SmartUI Selenium configuration documents options including waitForTimeout for lazy-loaded or asynchronous components, waitForPageRender for longer page rendering, enableJavaScript, and allowedHostnames for additional asset hosts. Those are SmartUI configuration details. The available references do not confirm that these options are present in the separate Screenshot Testing dashboard or its API, so do not copy them into that workflow unless its own documentation supports them.
- Check whether the page needs client-side JavaScript to show its main content.
- Check whether images or other assets load from a different hostname and whether that host is accessible.
- For a workflow that supports render waits, use its documented wait settings and allow enough time for the page’s actual behavior. A delay is not a guaranteed fix for blocked requests, broken scripts, or authentication failures.
- Compare the intended destination URL with the final page after redirects, if the tool provides that information.
6. Troubleshooting by symptom
| Symptom | Likely area to investigate | Next step |
|---|---|---|
| 400 response | Request or submitted values. | Check the URL, required fields, and request format against the API reference. The status alone does not identify the precise mistake. |
| 401 response | Authentication handling. | Verify the API’s required Basic authentication and the credentials supplied to the request. |
| 403 response | Access or authorization handling. | Review the response details and the account or resource access involved. Do not assume a 403 has one universal cause. |
| Local page unavailable | Cloud reachability. | Use the documented tunnel workflow and match any tunnel identifier to the active setup. |
| Login page appears instead of destination | Login workflow or field locators. | Use the login URL and verify the username, password, and submit locators. |
| Screenshot exists but is blank or partial | Navigation, scripts, render timing, or assets. | Confirm the destination and asset hosts; apply wait or JavaScript settings only in a workflow that documents them. |
| Issue persists after these checks | Test-specific failure. | Collect the test ID, timestamp, browser and OS configuration, redacted URL, and response or screenshot status for support. |
The API documentation describes retrieving screenshot-test details by test ID. Preserve that ID along with the evidence above so the failing run can be identified.
7. A practical diagnostic sequence
- Record the failure stage. Note whether the request itself errors, the page cannot be reached, login fails, or the captured page is incomplete.
- Validate the URL and request. Check the scheme, hostname, path, required URL value, Basic authentication, and API response.
- Check reachability from the cloud. If the site is local or private, configure and run the documented tunnel.
- Verify login behavior. Use the login URL and validate each form locator.
- Investigate rendering. Check JavaScript, asynchronous content, lazy loading, and asset hostnames. Apply only settings documented for the product workflow in use.
- Escalate with evidence. Include the test ID, exact time, browser and OS selection, a redacted URL, and the API response or screenshot status.
8. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Its API takes one GET request with a URL and returns an image or PDF. For example, this cURL request saves a WebP screenshot:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
See the ScreenshotNeo API documentation for the request options. Cookie banners are accepted like a visitor and removed, along with supported newsletter popups and chat widgets, before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. Its MCP server gives AI agents 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.
Sign up for 1,000 free screenshots a month, with no card required.
9. Performance, reliability, and cost considerations
For LambdaTest diagnosis, make one change at a time and record which run used which URL, tunnel, login settings, or rendering configuration. This makes it easier to distinguish an access problem from a timing problem. A longer wait can increase run time and still will not fix a URL that the cloud browser cannot reach, a rejected login, or an unavailable asset host.
Check the response and test details for each run before repeating it. The available research does not specify a universal timeout, a price for an individual failed screenshot, or a guaranteed fix for this error, so those should not be inferred from the status code or symptom alone. If cost predictability and explicit clean-page billing matter for a separate screenshot workflow, ScreenshotNeo states that only clean shots are billed and identifies the verdict and billing status in response headers; see its documentation for details.
10. Frequently asked questions
Why does the URL work in my browser but not in LambdaTest?
Your browser may have access to a local or private network that the remote cloud browser does not. For locally hosted pages, consult LambdaTest’s tunnel documentation and check the tunnel settings in the test request.
Does a 401 mean the website password is wrong?
Not necessarily. The API workflow uses Basic authentication, while a page’s own login form is a separate step. Check which request returned the status and use the authentication method documented for that step.
Will adding a wait fix a blank screenshot?
Only if capture timing is the problem and the workflow supports a suitable wait. A wait does not resolve an unreachable host, failed login, blocked asset, or JavaScript error.
Can I use SmartUI render settings in Screenshot Testing?
The cited settings are documented for SmartUI Selenium. The available references do not establish that the separate Screenshot Testing interface exposes the same settings.


