Applitools Eyes Baseline Mismatch After a Website Redesign: How to Fix It
A redesign can make an Eyes checkpoint differ from its baseline. Verify the run identity, review each change, then accept intended updates or investigate regressions.
A website redesign often changes the screenshot Applitools Eyes captures, so a baseline mismatch may be expected. Inspect the checkpoint and differences, verify that the run is using the intended application, test, operating system, browser, and viewport, then decide: accept and save intentional redesign changes, or reject unexpected changes and investigate them. Do not update the baseline until you have reviewed what changed.
An Eyes baseline is the expected image for a particular test and environment. Eyes compares a new checkpoint with that stored image and reports visual differences. A mismatch is a review signal; the title alone cannot identify its cause. You need the baseline and checkpoint images, run configuration, and test result to determine whether a specific change is intentional.
1. Inspect the mismatch before changing the baseline
Open the failed test in the Eyes Dashboard and inspect the checkpoint alongside the baseline and highlighted differences. Review the whole page and each changed region. Check whether the change matches the redesign specification, including text, typography, colors, graphics, and element positions.
- Open the test result and confirm which checkpoint failed.
- Compare the checkpoint with its baseline and examine the highlighted differences.
- Relate each material difference to the intended redesign. Look for unrelated changes as well as the planned ones.
- Keep the result unresolved while you check the run identity and determine whether to accept or reject the change.
Visual testing is intended to catch screens that changed unexpectedly. A redesign makes some changes expected, but it does not establish that every difference is safe.
2. Verify that this run uses the intended baseline
Before treating the comparison as a redesign update, check the baseline identity parameters associated with the run:
| Parameter | What to verify |
|---|---|
| Application name | The run is assigned to the intended application. |
| Test name | The checkpoint belongs to the intended test and matches the test whose baseline you reviewed. |
| Operating system | The run uses the intended OS baseline. |
| Browser | The browser matches the intended comparison environment. |
| Viewport size | The viewport matches the intended baseline dimensions. |
A difference in one of these parameters can mean the run is not comparing against the baseline you expected. Confirm the settings used by the run and compare them with the baseline identity before accepting an update.
3. Check the match level
Eyes match levels determine which visual changes are flagged. Strict is documented as the default. It detects visible changes to text, font, color, graphics, and element position while aiming to ignore rendering differences caused by platform-dependent software and hardware.
Use the match level that fits the test’s purpose. If the test should detect a visible text or layout change, do not loosen matching just to make the redesign run pass. If you believe a difference is caused by rendering variation, first confirm the environment and the test’s intended sensitivity, then adjust configuration deliberately. A match-level change does not establish that the application itself is correct.
4. Accept intentional redesign changes or reject regressions
Accept and save when the change is intended
If the checkpoint shows the approved redesign and you have verified that the run has the right identity, accept the change and save the baseline decision. The accepted visual state becomes the reference for future comparisons for that baseline.
Reject when the change is unexpected
If a difference is unrelated to the redesign, or you cannot explain it, reject the change and keep the existing baseline. Investigate the application, test data, and run environment; fix the cause, then rerun the test. Do not accept unexpected differences merely to clear a failure.
Review in the documented interface
The Eyes Dashboard supports reviewing changes and saving baseline decisions. For Playwright, Applitools also documents an enhanced HTML report for resolving changes. Accepting or rejecting changes in that report requires authentication. Use the review route that applies to your test setup, and confirm the decision is saved.
5. Troubleshooting common mismatch cases
| Symptom | Likely cause to check | Action |
|---|---|---|
| The mismatch looks like the wrong page or test | Application or test name differs from the baseline you intended to review. | Verify both identity values in the run and result, then open the matching baseline. |
| The page is broadly different after deployment | The run may have captured the redesigned site, or it may be using an unexpected environment or viewport. | Confirm the target deployment and baseline identity, then classify the changed regions against the redesign. |
| Text, color, graphics, or positions are flagged | These are visible differences Strict matching is designed to detect. | Decide whether each one is an approved redesign change. Accept intended changes; investigate unexpected ones. |
| Differences persist across runs | The application may still produce a visual state that differs from the saved baseline, or the runs may not share the intended identity. | Compare run identity and images across the result history. Fix the application or configuration if the difference is not intended. |
| A reviewer cannot accept or reject in the Playwright HTML report | The documented report’s change-resolution actions require authentication. | Authenticate, or use the Eyes Dashboard review workflow, then save the decision. |
| Accepting a change does not resolve the expected comparison | The baseline decision may not have been saved, or the next run may use another baseline identity. | Confirm the save completed and recheck application, test, OS, browser, and viewport on the next run. |
These are diagnostic checks, not claims about the root cause of a particular failure. The actual cause requires inspecting the checkpoint, baseline, run configuration, and result.
6. Performance, reliability, and cost considerations
For reliable visual comparisons, keep the application, test, OS, browser, and viewport intentional and consistent with the baseline you mean to use. Review changes before updating the reference; otherwise, an unintended visual state can become the expectation for later runs. Choose a match level based on what the test must detect, and save baseline decisions through the documented review workflow.
The supplied documentation for this issue does not establish specific runtime, pricing, or cost figures, so none are assumed here. For current Eyes configuration and commercial details, consult the relevant Applitools documentation and account information.
Or skip the browser setup
If you need a screenshot of a page to inspect a visual change outside your Eyes run, ScreenshotNeo provides a website screenshot API and MCP server. Its API can return a PNG, JPEG, WebP, or PDF with one GET request. See the ScreenshotNeo API documentation for parameters and response details.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport 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}`);ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots, and every feature is on every plan.
Sign up free for 1,000 screenshots a month, with no card required.
FAQ
Does a baseline mismatch mean the redesign is broken?
No. It means the checkpoint differs from the stored image. Review the differences and run identity to determine whether the change is expected.
Should I accept every mismatch after a redesign?
No. Accept only reviewed, intentional changes. Reject and investigate differences you cannot explain.
What should I check first if the result seems unrelated to my redesign?
Check the application name, test name, OS, browser, and viewport, then compare the actual checkpoint and baseline.
Does changing the match level update the baseline?
A match level controls which differences are flagged; it is separate from reviewing and saving a baseline decision.
Where can I resolve a Playwright visual change?
Use the Eyes Dashboard or the documented enhanced Playwright HTML report. The report requires authentication for accept/reject actions.
