Compare / Applitools

Screenery vs Applitools Eyes

Applitools Eyes matches screenshots with its Visual AI and sells to teams that need cross-browser grids, PDFs and enterprise controls. Screenery is smaller: it compares pixels, and it publishes each accepted screenshot at a URL you can embed.

What Applitools does well

• Visual AI. Match levels compare what a person would notice rather than every pixel, which cuts noise from dynamic content such as ads and timestamps.
• Coverage. The Ultrafast Grid renders across browsers and devices. Eyes also checks PDFs and documents, and it can use Figma frames as baselines.
• Agents, already. The Eyes MCP server lets an agent inspect diffs and accept, reject or mask baselines. Applitools has also published a GitHub Actions recipe in which an agent triages failed visual tests and posts a summary on the pull request. Screenery is not first at agent reports.
• Enterprise. SSO, SOC 2, dedicated cloud or on-premises deployment, and named support.

Side by side

Applitools pricing, checked October 2026

From Applitools' pricing page.

There is no free plan. Starter offers a free trial.

Where Screenery differs

Published screenshots. An Eyes baseline is a test artefact in a dashboard. Screenery gives every accepted screenshot a plain image URL that follows your default branch, so docs and READMEs stay current:

![Billing](https://cdn.screenery.dev/acme/dashboard/settings/billing@latest.png)

A pull request lands on @pr-N and never moves @latest. Every push is also a version whose URL never changes. See Screenshot URLs.

Plain pixels, graded. Screenery does not use AI to decide whether a change matters. It compares pixels and grades each changed region as minor, moderate or major, and the same two PNGs get the same grade on every machine. You choose which grade fails. See Graded changes.

No key in CI on GitHub Actions. The Action trades GitHub's OIDC token for a credential that lasts five minutes. There is nothing to store or rotate.

A smaller first step. One workflow step publishes the folder your tests already write. There is no SDK to add to each test.

When to pick Applitools instead

• Dynamic pages make pixel diffs noisy, and you want AI matching to filter them.
• You need many browsers and devices rendered for you, or PDF and document checks.
• You need on-premises deployment, SSO or a regulated-industry contract.
• You want an agent to accept or reject baselines for you through MCP.

Moving a Playwright suite

Each eyes.check() call becomes a page.screenshot() call with a path. The path is the screenshot's name:

import { test } from '@playwright/test';

test('billing settings', async ({ page }) => {
  await page.goto('/settings/billing');
  await page.screenshot({ path: 'test-results/settings/billing.png', fullPage: true });
});

Remove the Eyes SDK setup and the API key secrets, then add the Action after your tests:

permissions:
  id-token: write
  contents: read
  pull-requests: write
steps:
  # … check out, install, run your Playwright tests …
  - uses: screenery/push@v1
    with:
      project: acme/dashboard
      path: test-results

To fail a pull request on a visual change, commit a baseline folder and set diff-baseline. Masking dynamic content is Playwright's job: page.screenshot({ mask: [locator] }) covers the element with a solid box before the file is written. See Visual testing and Getting started.

Sources

Checked October 2026.

• Applitools pricing
• Applitools Eyes
• Applitools What's New
• Applitools: Let Agents Review Your Visual Test Failures in GitHub Actions

See also: all comparisons.