Applitools review: pricing, alternatives and setup

Each call to eyes.check in a test creates a checkpoint. The first time a test runs in a given environment, its checkpoints become the baseline and the test is reported as new. On later runs, each checkpoint is compared with the baseline and any difference is flagged as unresolved until someone accepts it, which updates the baseline, or rejects it as a bug. Applitools identifies a baseline by application name, test name and an environment made of operating system, browser and viewport size. Changing any of those, for example renaming a test or resizing the viewport, creates a new baseline rather than a comparison, which is the most common source of confusing new results.

The comparison is not a pixel diff. Match levels set what counts as a difference. Strict aims to flag changes the human eye would notice in text, fonts, colours, graphics and position, while ignoring rendering differences between machines. Layout checks only the relative positions of elements and ignores their content. Ignore Colors behaves like Strict without colour. Dynamic recognises text patterns such as dates, email addresses and URLs, so a changed date in a valid format is not flagged; Applitools documents it as the default for web tests on supported SDK versions. Exact is a pixel-for-pixel comparison that the documentation does not recommend for ordinary verification.

With the classic runner, the SDK takes a screenshot in the browser your test is driving and uploads it, so cross-browser coverage means running the test in every browser. With the Ultrafast Grid, the SDK instead captures a DOM snapshot with the page’s HTML, CSS, images and other resources, uploads it, and Applitools renders it on its own browsers and devices in parallel; the local browser is used only to determine what the page needs. Unchanged resources are cached between checkpoints. The result is broad coverage from one local run, with one caveat in the documentation: the local viewport must be compatible with the target configurations, or captured content can differ.

In Playwright, the recommended integration since SDK 1.32 is a custom fixture: tests import test from @applitools/eyes-playwright/fixture and receive an eyes object alongside page. Configuration lives under eyesConfig in playwright.config.ts, and results for a run are grouped into a batch in the Eyes dashboard. The failTestsOnDiff setting decides when a visual difference fails Playwright: after each test, after all tests, or never. The fixture’s source defaults it to afterAll when the CI environment variable is set and afterEach otherwise, so the same suite reports differences at different moments locally and in CI.

Keep Eyes configuration in playwright.config.ts so every test shares the same application name, batch, browsers and branch settings. Choose the Ultrafast Grid with type ufg when you want cross-browser coverage from a single Playwright project, and list the renderings in browsersInfo. Name the batch after the pipeline run so results group sensibly in the dashboard. Read the branch name from CI so feature branches get their own baselines, with main as the parent. Leave failTestsOnDiff at its default unless you have a reason: per-test failures locally, one failure after the run in CI.

Most false diffs come from a handful of regions: timestamps, adverts, personalised greetings, carousels and live data. Deal with them at the checkpoint rather than by lowering the match level for the whole page. Ignore regions remove an area from comparison entirely; layout regions keep checking structure while allowing content to change; strict regions protect areas that must not move, such as a price or a legal notice. Also stabilise what you can before checking: wait for fonts and data, close cookie banners, and freeze animations. Where a test is about one area, checking that region rather than the full page also makes failures easier to read.

Visual tests run as ordinary Playwright tests, so the pipeline needs only the API key as a secret and the branch name for baseline branching. With the Ultrafast Grid, one Chromium install is enough, because rendering in other browsers happens in Applitools’ cloud. Because failTestsOnDiff defaults to afterAll in CI, expect individual tests to pass and the run to fail at the end when there are unresolved differences; the Eyes reporter and dashboard show which ones. Applitools also offers a GitHub integration that reports results as checks on the pull request.

Visual testing succeeds or fails on review discipline. Decide who reviews differences, usually the developer of the change with a designer or QA lead for intentional redesigns, and how quickly unresolved results must be cleared, since they block the pipeline. Accept differences on the feature branch, where branch baselines keep them isolated, and let them reach main when the branch merges. Reject differences that are bugs so they stay visible on the next run. Avoid accepting in bulk without looking at each difference. Rename tests and change viewports deliberately, since either creates new baselines.

Checkpoints cost money and review time, so place them where a visual regression would hurt and functional assertions are weak: key templates, design system components, marketing pages, checkout and anything with complex responsive behaviour. Prefer one well-placed full-page checkpoint per state over a check after every step. For component libraries, the Storybook SDK checks stories directly, which suits the component checkpoints the pricing page describes. For responsive designs whose layout changes through JavaScript rather than CSS, configure layoutBreakpoints so the SDK captures a snapshot at each width instead of letting the grid render one snapshot at sizes it was not built for.