How to Compare Screenshots Across Browsers in BrowserStack

To compare screenshots across browsers in BrowserStack, use Percy cross-browser visual testing: select the browsers, capture the same page and state, compare each browser render with its approved baseline, inspect the differences, and approve only changes that are intentional. Percy manages the rendering environment for its browser selection. If you need to choose the operating system and browser versions yourself, configure a BrowserStack Automate platform instead.

This workflow is for visual regression testing: it tells you what changed in a rendered page. It does not decide whether a difference is a bug. A reviewer must interpret the results and approve the intended changes.

1. Choose how to configure browser coverage

Start by deciding whether you need Percy-managed browser selection or explicit environment control.

Need	Use	What you control
A managed set of modern desktop browsers	Percy browser settings	Select supported browsers. BrowserStack manages and updates the available browser versions and operating systems.
A specific OS, OS version, browser, and browser version	BrowserStack Automate platform configuration	Specify all four platform dimensions in the test configuration.

BrowserStack documents Chrome, Firefox, Edge, and Safari as defaults for new Percy projects. Availability can change as BrowserStack manages the underlying versions and operating systems, so check the current cross-browser settings documentation when configuring a project.

Use Percy-managed browser settings

Open your Percy project settings and enable the browsers you want to compare.
Keep the page, application data, viewport, and capture timing consistent across runs.
Run the visual test. Percy renders the captured page for each configured browser and creates browser-specific screenshots and comparisons.

The exact setup steps depend on your integration. BrowserStack supports the BrowserStack SDK route, which combines functional and visual testing, and the Percy SDK route, which can be integrated manually with supported application and end-to-end test setups. Check the current supported SDKs documentation for framework-specific setup and configuration.

Use Automate for explicit OS and browser versions

Choose Automate when a test needs a particular operating system or browser version rather than Percy’s managed environment. Include the OS name, OS version, browser name, and browser version in the platform configuration. Use the platform format and supported values in the current BrowserStack documentation for your SDK; do not assume that a configuration example for one test runner works unchanged in another.

Percy’s managed browser settings do not let you select the underlying operating system. If you need to compare native rendering across operating systems, configure those environments through Automate. BrowserStack describes Automate and App Automate as routes to broader browser, viewport, and device coverage.

2. Capture the same page and state

A useful browser comparison starts with equivalent inputs. For every browser, capture the same URL or route, application data, logged-in state, viewport dimensions, and point in the test flow. A page captured before an animation finishes in one browser and after it finishes in another can produce a diff that says more about timing than about a real design change.

Load a known test fixture or otherwise stabilize the application state.
Navigate to the same page and reach the same interaction state in every run.
Wait for content that affects the screenshot, including asynchronous data and images, to settle.
Capture the page at comparable widths. Add responsive widths as separate coverage when layout behavior matters.
Review the result for each selected browser. Each browser snapshot counts toward monthly screenshot usage.

For broad visual coverage, BrowserStack recommends verifying the full page. For routine comparisons, it recommends Percy’s Recommended match level. These are vendor recommendations; the appropriate capture scope and match settings depend on what your team needs to detect. See the Percy recommended guidelines.

3. Compare against the correct baseline

A baseline is an earlier render that a reviewer approved. Percy selects the comparison build according to the project’s baseline strategy. Before interpreting a diff, confirm that the comparison is against the right approved build and that the browser has a usable baseline.

A newly enabled browser may not have a historical baseline. Its first run captures a render, but cannot show a meaningful change against an earlier render for that browser. Review that initial result and establish an approved baseline before treating later runs as regressions.

Percy offers different approval scopes:

Baseline strategy	Approval scope	Choose it when
Git baseline management	Approval applies at the whole-build level.	The team wants to accept or reject a build’s set of visual changes together.
Visual Git	Snapshots can be approved individually.	The team needs to accept some snapshots while holding others for changes or review.

Review the project’s strategy and branching behavior in BrowserStack’s baseline management documentation. The baseline strategy changes what a reviewer is approving, so align it with the team’s review process.

4. Inspect browser-specific differences

Review each browser result separately. BrowserStack’s Test Companion web visual-analysis workflow provides side-by-side, overlay, and diff views, and lets reviewers switch among captured browsers and widths. Use these views to locate the change, then inspect the page and test state to understand it. See visual analysis for web apps.

A difference can be an application regression, an intended design change, or a rendering-environment difference. BrowserStack specifically calls out system fonts, form controls, and scrollbars as examples of OS-level differences. Percy-managed browsers run on fixed operating systems managed by Percy, so an OS-specific discrepancy may require a separate Automate comparison if the operating system itself is part of the requirement.

A review checklist

Is the baseline from the intended branch or approved build?
Does the new browser have an established baseline?
Are both screenshots for the same page, data, viewport, and interaction state?
Does the difference affect the application, or could it come from fonts, native controls, scrollbars, or the OS?
Is the change expected and approved by the design or product owner?
Are the selected browser and width sufficient for the behavior being checked?

5. Approve or fix the result

Approve a change only after confirming that it is intentional. If the diff shows a regression, leave the build unapproved, fix the application, and run the visual test again. Percy presents the render and comparison; the reviewer decides whether the new appearance should become the baseline.

Where a build has many snapshots, use the project’s baseline strategy deliberately: whole-build approval can accept a larger set together, while per-snapshot approval allows individual decisions. Keep review notes or your team’s normal change context with the decision so that future reviewers can understand why a visual change was accepted.

Options and coverage decisions

Question	Practical choice
Need broad browser coverage?	Use Percy-managed browser selection and review the supported set in project settings.
Need a named OS and exact browser version?	Use Automate and specify OS name, OS version, browser name, and browser version.
Need responsive layout checks?	Capture the relevant widths and compare each width consistently across runs.
Need device or platform coverage?	Use BrowserStack’s Automate or App Automate routes where the project requires broader browser, viewport, or device combinations.
Need whole-build or individual acceptance?	Choose Git baseline management for whole-build approval or Visual Git for per-snapshot approval.
Need visual inspection tools?	Use side-by-side, overlay, or diff views in the visual-analysis workflow.

Performance, reliability, and usage planning

Each selected browser generates a separate screenshot that counts toward monthly usage. Browser count therefore affects screenshot consumption: add browsers because they cover a risk the team cares about, and include responsive widths or device combinations intentionally. Check BrowserStack’s current pricing and usage terms directly before estimating a project’s budget; this guide does not state plan limits or prices.

For more reliable comparisons, keep the capture state and timing stable and make sure the relevant content has loaded. Unstable data, animations, late-loading assets, and environment-specific native rendering can create noise. A screenshot system can report a difference consistently while the underlying cause still needs human diagnosis.

BrowserStack recommends isolating screenshot calls in a wrapper so integration changes stay localized. That is useful when test code may evolve: centralizing capture behavior makes it easier to adjust the integration without editing every test. See the recommended guidelines.

Troubleshooting

Symptom	Likely cause	What to do
A browser has no meaningful diff on its first run.	The browser was newly enabled and has no earlier approved baseline.	Review the initial render, establish its baseline, then compare subsequent runs.
The same page shows different changes between runs.	Application state, data, viewport, or capture timing changed.	Stabilize the fixture and interaction state; use the same viewport and wait for relevant content before capture.
A difference appears only in one browser or OS.	It may be a browser-specific application issue or OS rendering difference.	Inspect the browser result and consider fonts, form controls, scrollbars, and the underlying OS. Use Automate when explicit OS comparison is needed.
A whole set of snapshots was accepted unexpectedly.	The project may use whole-build Git baseline approval.	Check the baseline strategy. If reviewers need independent decisions per snapshot, evaluate Visual Git.
The screenshot usage is higher than expected.	Each selected browser creates a counted screenshot; additional widths and combinations add coverage.	Review browser and width selection against the risks the suite is intended to catch, then verify current usage terms.
A test integration does not match an example.	BrowserStack SDK and Percy SDK setup depends on supported framework and runner configuration.	Check the current supported SDK list and the integration guide for that framework.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. It can return a PNG, JPEG, WebP, or PDF from one GET request. It captures a page from a URL; use Percy when you need BrowserStack’s cross-browser baseline workflow and browser-by-browser visual review.

This runnable cURL request saves a WebP screenshot. See the ScreenshotNeo API documentation for options and configuration.

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

Cookie banners are accepted and removed before the shot, along with known newsletter popups and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server lets AI agents using Claude, Cursor, or another MCP client take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. The same features are available on every plan.

FAQ

Does Percy choose whether a visual difference is acceptable?

No. Percy shows the comparison; a reviewer approves intentional changes or leaves regressions unapproved for a fix and rerun.

Can Percy-managed settings test a specific operating system?

No. Percy manages the operating systems behind its browser selection. Use Automate configuration when the OS and version must be explicit.

Will enabling a browser immediately show changes against history?

Not necessarily. A newly added browser may need an initial render and approved baseline before later runs have a historical comparison.

Which Percy integration should I use?

Use the BrowserStack SDK for its combined functional and visual workflow, or integrate the Percy SDK manually when your supported application and test setup calls for it. Confirm current framework support in the SDK documentation.