Everything PixellPeep can do

What visual regression testing catches

Functional tests answer “does the button still work?” They stay green when the button is invisible, overlapping the footer, or rendered in the wrong brand colour. Visual regression testing closes that gap: it compares a screenshot of your interface against a known-good baseline and flags what changed, so layout damage is caught before a user sees it.

That matters most when the change didn’t come from your own pull request — a dependency bump, a CSS framework upgrade, a third-party widget, or a CMS plugin update. There’s no diff to review in those cases, which is exactly when an automated screenshot check earns its keep.

How the workflow fits together

1. Capture. Take a screenshot from your existing Playwright, Cypress or Puppeteer test, from the CLI, or by uploading images directly.
2. Compare. The image is checked against the stored baseline using whichever algorithm suits that screen.
3. Review. Differences are highlighted in a shared report, with an AI summary describing what actually changed.
4. Gate. The build fails when a difference exceeds your tolerance — so regressions stop at CI, not in production.
5. Approve. When a change is intentional, accept it and it becomes the new baseline.

Drops into the tests you already have

You don’t rewrite your suite. Install the SDK for your framework and add a snapshot call where you want a visual check — your selectors, fixtures and test logic stay exactly as they are.

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

test('checkout page', async ({ page, pixellpeep }) => {
  await page.goto('/checkout');
  await pixellpeep.snapshot('checkout');
});

Baselines are stored centrally rather than committed to your repository, so there are no screenshots bloating git and no drift between a developer’s machine and the CI runner — the failure mode that sinks most self-hosted visual testing setups.

Frequently asked questions