How to Approve Visual Differences in Applitools Eyes

Short answer: inspect the checkpoint against its baseline, then accept the difference if it is an intended product change or reject it if it is an unintended regression. Accepting makes the checkpoint the baseline for future comparisons after the change is saved; rejecting keeps the existing reference and leaves the difference needing attention.

A baseline is the expected screenshot for a visual test checkpoint. The first run establishes baseline images; later runs compare their checkpoints with those references and report differences. See Applitools’ overview of visual UI testing for the lifecycle.

Review a visual difference before approving it

Open the test result in the Applitools Dashboard or the review surface your integration provides. In the Dashboard, find the relevant test and open the step with the difference.
Compare the baseline with the new checkpoint. Use side-by-side or toggle views to understand what changed; an overlay can help locate changed areas. Do not decide from a red or green status alone.
Inspect the changed region in page context. Check whether the change is expected, whether it appears on related steps, and whether it could reflect a broken asset, changed content, timing issue, or rendering difference.
Choose Accept (also called approve in some surfaces) if the change is intentional and should become the expected result. Choose Reject if it is unexpected and should be investigated or fixed.
Save or apply the decision if the review surface requires it. Confirm the result is resolved and that the saved baseline is the one you intend future test runs to use.

The Applitools Dashboard guide documents comparison views, region annotations, and its accept, reject, and save controls. Exact labels and workflow can vary by integration and deployment.

When to accept or reject a change

Decision	Use it when	Effect
Accept	The checkpoint reflects an approved feature, design, copy, or other deliberate UI change.	The accepted checkpoint becomes the baseline reference for future comparisons once saved.
Reject	The change is unintended, unexplained, or indicates a product or test defect.	The previous reference is retained and the difference remains a matter to investigate; in the enhanced Playwright report, rejecting keeps the test failed.

Acceptance is a baseline change, not just a way to clear a warning. Before accepting, make sure the change belongs in the product and that the test is comparing the intended application state. If a difference is caused by unstable content or a test setup problem, accepting it can make an incorrect result look normal on later runs.

Inspect the changed region and its scope

First determine what changed in the actual page. The Dashboard documentation describes side-by-side and toggle comparison modes, colored difference overlays, and region handling options. Depending on the case, a region can be marked as ignore, floating, strict, dynamic, ignore-colors, or layout. These settings change how Eyes evaluates a region; they do not answer whether a product change was intended.

Ignore: consider whether a region truly should not be checked. Ignoring a region can hide future defects there.
Floating: consider this when an element may move within a bounded area but should otherwise remain visually consistent.
Strict: use when the region needs stricter visual matching.
Dynamic: consider for predictable changing content where Eyes should tolerate expected variation while still checking the region.
Ignore colors: consider when color changes alone are not meaningful, while layout and content still matter.
Layout: consider when structure and flow matter more than the exact content within a region.

Check scope as well as intent. A change limited to one expected step may be straightforward to accept. Similar diffs across many steps or environments could reflect a shared UI change, but could also reveal a broad regression. Review representative affected steps before applying any bulk action. Older Applitools Help Center guidance describes accepting or rejecting similar or all steps, but it dates from 2018; verify that the controls and labels are available in your current interface.

Save the baseline update

Some review surfaces distinguish resolving a difference from saving the updated baseline. After accepting, look for an explicit save or apply action and complete it. Then verify that the result reflects the intended decision. Applitools’ visual testing overview says saved updates are used in subsequent runs.

Baseline context can depend on how the test and environment are configured. A legacy Applitools Help Center article describes baselines associated with a test and environment, including operating system, viewport, browser, application name, and test name. Treat that list as historical guidance and confirm the current behavior for your integration and account: What is a baseline?

Reviewing in the enhanced Playwright report

If your team uses the Applitools enhanced Playwright report, it supports reviewing differences and accepting or rejecting them from the report. In that surface, accepting saves the checkpoint as the baseline, and rejecting indicates an unintended difference and leaves the test failed. Report viewing and permission to change a baseline are separate: the documentation says baseline images are not shown to logged-out viewers and authentication is required to accept or reject. Check the instructions for your actual review surface rather than assuming those exact access rules apply to every Eyes interface.

See Applitools’ Playwright integration documentation for report-specific details.

Common mistakes and troubleshooting

Symptom	Likely cause	What to do
The same difference appears on later runs.	The accepted update may not have been saved, or the later run may use a different baseline context.	Return to the result, check whether the decision is saved, and confirm the test and environment correspond to the baseline you meant to update.
You cannot accept or reject in a report.	The review surface may require authentication or permission to modify baselines.	Sign in with an account authorized to update baselines. For the enhanced Playwright report, Applitools documents authentication for accept/reject actions.
A large number of steps show differences.	A shared intended UI change, a broad regression, or a common test/environment change may affect multiple checkpoints.	Compare several representative steps and environments. Accept a group only when the shared change is understood and intended; otherwise investigate the common cause.
A region changes on every run.	The content may be dynamic, or the page may be captured in an unstable state.	Check whether the test waits for the page to reach the intended state. If the variation is expected, assess the appropriate region behavior and its effect on coverage.
The diff seems cosmetic, but you are unsure whether to approve it.	Color, antialiasing, content, or layout differences can look similar at a glance.	Use comparison modes and inspect the page context. Confirm whether the product change was approved and whether the visual result is correct before changing the reference.
You cannot find the same button names shown in a guide.	The guide may describe another integration or an older Dashboard interface.	Follow the controls in your active review surface and its current integration documentation. The 2018 Help Center workflow may not match current labels.

Reliability and review practices

Review the visual evidence before changing a baseline; a passing test after acceptance only means the new reference is now being used.
Keep the decision tied to intent: accept approved UI changes, reject unexplained or incorrect ones, and investigate uncertain differences before resolving them.
Save changes explicitly where the interface asks for it, then confirm the result is resolved.
Use region rules to model known variation carefully. A broad ignore rule can suppress useful regression signals.
For group or bulk resolution controls, review a representative sample first and confirm the action’s scope in the current interface.

Or skip the browser setup

Applitools Eyes is for comparing test checkpoints with managed baselines. If you also need a clean screenshot of a live page for a report, issue, or agent workflow, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It is separate from Eyes and does not approve Eyes baselines.

One GET request returns an image or PDF. For example, save a WebP screenshot with cURL:

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 and removed before the shot, along with known newsletter popups and chat widgets; each of these steps can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and the response identifies 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 shots a month without a card; paid plans start at $5 for 3,000 shots.

FAQ

Does accepting a difference change the screenshot from the current run?

Acceptance changes the reference used for future comparisons after the update is saved. It does not mean the underlying application was changed.

Should I accept a difference just to make a test pass?

No. Accept only after confirming the checkpoint is the intended new appearance. Otherwise, investigate and reject the difference until its cause is understood.

Does rejecting delete the checkpoint?

The cited Eyes guidance describes rejection as marking the difference unintended and retaining the existing baseline. The exact result status and controls depend on the review surface; the enhanced Playwright report keeps a rejected test failed.

Can I approve only part of a screenshot?

Eyes documentation describes region annotations that change how selected areas are evaluated. These region rules are different from deciding whether the overall product change is intentional.