Applitools Eyes Baseline Management for Multiple Browsers

Applitools Eyes manages baselines per test environment by default, including the browser, operating system, and viewport size. For browser-specific visual regression, keep those separate references. For a cross-browser structural check, deliberately configure a shared Baseline Environment Name and use Layout matching. Review differences in Eyes Test Manager before accepting any change.

The right setup depends on what a test should detect: pixel-level visual changes within one browser, or structural differences across environments. Those are different test goals, and a shared reference is not a substitute for browser-specific visual review.

1. Choose what your browser tests should compare

Approach	Reference model	Use it for	Trade-off
Environment-specific baselines	One baseline per test and environment combination	Browser-specific regression testing; Strict matching where content is stable	More references to review and maintain
Shared cross-environment baseline	A Baseline Environment Name associates runs with one reference environment	Checking page structure across browsers, operating systems, or viewport sizes	Layout matching ignores some visual differences, including text, graphics, color, and other styling
Baseline variations	Several accepted images for a test step	Legitimate alternatives such as A/B-tested content	Up to 20 variations are documented per step; each should represent an intentional expected result

Eyes identifies a baseline using the application name, test name, operating system, viewport size, and browser. A new environment combination can establish a new baseline. So a Firefox run does not automatically reuse the Chrome baseline: separate browser references are the default. Applitools documents the baseline identity and environment-specific behavior.

2. Set up environment-specific baselines

1. Run the same visual test in each target browser and environment. Keep the application and test names consistent when the runs represent the same test.
2. Let the first run in each environment establish its reference image. A previously unseen browser, operating system, or viewport combination may produce another baseline.
3. Use Strict matching when the goal is to detect close visual changes within that same environment and page content is mostly stable.
4. Review each environment’s result in Eyes Test Manager. Accept an intentional change to update its reference; reject a difference that represents a defect.

This model answers, “Did this page change in Chrome compared with the accepted Chrome rendering?” and separately, “Did it change in Firefox compared with the accepted Firefox rendering?” It does not require the browsers to render identically.

3. Configure a shared cross-environment baseline

Use a Baseline Environment Name when the test objective is to compare runs across browsers, operating systems, or viewport sizes against a shared reference. The name is associated with one environment, which acts as the reference for other runs using that name. Set the value before opening the Eyes test.

1. Choose the reference environment and configure the Baseline Environment Name using the option supported by your framework and SDK version.
2. Set the same name for the other browser or environment runs that should use that reference.
3. Use Layout matching for this cross-environment check. Applitools recommends it because browsers and operating systems can have visible rendering differences.
4. Inspect the results in Eyes Test Manager and decide whether each detected difference is intentional before updating expectations.

The cross-environment guidance is described in an Applitools Help Center article updated in 2021. SDK APIs and UI labels can change, so check the current documentation for your framework and SDK version before copying a method signature. The configuration concept is stable in the cited guidance; the exact code to set it is SDK-specific.

Layout matching checks relationships and positions among elements while disregarding text, graphics, color, and other style changes. It is useful for structural comparison, but it cannot tell you whether a color regression or changed label is acceptable. Keep environment-specific Strict tests when those details matter. See Applitools’ match-level documentation.

4. Review and update references safely

1. Open the completed test in Eyes Test Manager and inspect the changed regions in context.
2. Determine whether the difference is an intended product change, an environment-specific rendering difference, or a defect.
3. Accept only intended changes to save them as the expected result. Reject unexpected changes to retain the prior expectation.
4. When a difference is legitimate only for a particular step, consider a baseline variation rather than loosening matching across the whole test.

Acceptance changes what future runs expect. Treat it as a review decision, not a routine way to clear every diff. Applitools describes this inspect-and-save workflow in its Eyes overview.

5. Use baseline variations for intentional alternatives

A baseline variation gives one test step more than one accepted reference. A checkpoint passes if it matches any saved variation. This can fit legitimate alternatives such as an A/B-tested page, where either of two known designs is expected. Applitools documents a maximum of 20 variations per step. Check its baseline variations guidance.

Use variations at the step where alternatives are expected. They do not make an entire browser suite cross-environment, and they are not a reason to accept unexplained differences.

6. A practical multi-browser workflow

1. Write down the assertion. Decide whether the test checks visual fidelity within each browser or structural consistency across browsers.
2. Choose the reference model. Use environment-specific baselines for browser-specific regression. Use a Baseline Environment Name for an intentional shared structural comparison.
3. Choose matching for the assertion. Use Strict for close visual review within a stable environment. Use Layout for cross-environment structure.
4. Run the target matrix. Keep test identity consistent and record browser, OS, viewport, and any relevant test data so a new baseline is explainable.
5. Review every new or changed reference. Accept intentional UI changes, reject defects, and use step variations only for expected alternatives.
6. Revisit the model when the test changes. If a structural check must also catch typography or color changes, add or retain browser-specific visual checks.

7. Troubleshooting

Symptom	Likely cause	What to do
A browser run creates a new baseline instead of comparing to another browser’s image	Browser is part of the default environment identity	Keep separate baselines for browser-specific checks, or deliberately configure the same Baseline Environment Name for a shared comparison.
The shared comparison reports many visual differences	Strict or another close visual match level is being used across unlike environments	For a structural cross-environment test, use Layout matching as Applitools recommends. Keep separate Strict tests for styling fidelity.
A color, font, text, or image change is not flagged by the structural test	Layout matching disregards content and style differences	Add or retain environment-specific visual regression checks for those properties.
A baseline changes after a viewport or OS change	Viewport and OS are part of baseline identity	Confirm the environment is intentional. Run it as its own reference, or configure an explicit shared environment if the test is meant to compare across it.
Accepting a result hides a regression in later runs	An unintended change was saved as the expected image	Review diffs before acceptance. Reject defects and restore the intended reference through the applicable Eyes Test Manager workflow.
A legitimate A/B result still fails	The alternate result is not an accepted reference for that step	Save a deliberate baseline variation for the step, within the documented limit of 20.
An example configuration method is missing or fails to compile	The example targets another framework or SDK version	Use the current documentation for the exact SDK and set the Baseline Environment Name before opening the Eyes test.

8. Performance, reliability, and maintenance

Baseline management does not eliminate the need to control the test environment. Keep browser, OS, viewport, application data, and dynamic page state predictable when you expect a close visual comparison. Otherwise, a test may create extra references or show changes unrelated to the code under test. The documented baseline identity itself explains why environment changes matter.

Separate baselines preserve browser-specific evidence, but add references to review. Shared Layout comparisons reduce the emphasis on text and styling differences, which makes them useful for structural checks but insufficient for full visual coverage. A layered suite can use both: shared structural checks across browsers and Strict checks in selected browser environments.

There are no performance benchmarks in the cited material for these baseline strategies. The operational cost is primarily the review and maintenance effort implied by the number of environments, references, and legitimate variations. Keep the browser matrix aligned with the risks the tests are meant to catch.

9. Capture clean browser evidence with ScreenshotNeo

Applitools Eyes is for visual testing and baseline review. If you also need a screenshot artifact from a URL without setting up a browser capture script, ScreenshotNeo is a website screenshot API and MCP server. It does not replace Eyes baseline management; it can provide clean screenshots for documentation, debugging, or agent workflows.

Or skip the browser setup

Make one GET request; see the ScreenshotNeo API documentation for options.

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

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

• Cookie banners are accepted like a visitor, and known consent banners, newsletter popups, and chat widgets are removed before capture; each step can be turned off.
• Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers identify page verdict and billing.
• An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents.
• The free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; every feature is on every plan.

Sign up for 1,000 free screenshots a month, with no card.

10. FAQ

Does Eyes automatically use one baseline for Chrome and Firefox?

No. The default baseline identity includes the browser, so each browser can establish its own reference.

Does Layout matching mean the pages look the same?

No. It checks structure and ignores several content and style differences, so it is not full visual equivalence.

How many baseline variations can one step have?

Applitools documents up to 20 variations for a test step.

Should I accept all diffs after a browser update?

No. Inspect them and accept only changes that are intentional for the test.

Sources

• Applitools: Baselines
• Applitools: Match levels
• Applitools: Baseline variations
• Applitools: Eyes overview