UI Verify vs Playwright screenshots

Playwright's built-in visual comparison is free and lives in your test runner: it screenshots a page and diffs it against a baseline image committed next to the test. UI Verify runs the same comparison but moves the baselines, the review, and the judgment off your repo and CI. For the wider landscape, see visual regression testing tools compared.

• Real-browser screenshots diffed pixel by pixel against a baseline.
• You can drive a real page or a component, not just a Storybook story.
• Knobs to tame false diffs - Playwright has mask, stylePath, threshold, and maxDiffPixelRatio, and disables animations by default.

• A fixed render environment, not a per-OS baseline chore. With native Playwright the screenshot rasterizes on whatever machine runs it, so a baseline from your Mac will not match the CI Linux box and teams pin a Docker image to keep per-OS baselines. UI Verify replays every capture in one fixed environment and neutralizes the render-time flake it can see from outside your app - inlined cross-origin fonts, a fetch-once image cache, a hermetic network, and prefers-reduced-motion. The clock, live data, feature flags, and a random pick made during server rendering live inside your app, so you pin those in the test or the component (isUIVerify()). See Fix flaky visual tests.
• Observability over changes, not a zip to download. Native Playwright reports a visual change as a failed test. To see what moved you leave the pull request, open the CI run, download the report artifact, unzip it, and open the expected, actual, and diff PNGs by hand - or you re-run and hope it was flake. UI Verify puts the diff on the pull request itself, with a review queue and per-story history, so a change is something you accept or reject inline, not a test you re-run with --update-snapshots.
• Hosted, git-aware baselines. No screenshot images committed to your repo and no per-OS baseline files to juggle - baselines live in the service, one per branch, resolved from your git history.
• An AI judge, and an agent that never leaves its loop. UI Verify labels each change a regression or an intended change, holds the pull request when it flags a regression, and exposes the diffs and verdicts over MCP - the changed region cropped as a before-and-after image your coding agent reads in the same context it opened the PR from. The agent never downloads an artifact, unzips it, or opens PNGs by hand, and it accepts the intended baselines without a human clicking through a dashboard. Playwright ships its own MCP and test agents, but they drive the browser and generate tests - they do not review visual diffs. See the AI judge, Triage with your agent, and the cropped-diff review unit.
• Automatic flake detection. A change that does not reproduce on a re-render is auto-ignored, so a flaky screenshot does not fail your build. See automatic flake detection.

The gap is clearest on a single changed pixel. With native Playwright the check goes red and the log says how many pixels differ. To see what moved you open the CI run, download the report artifact, unzip it, and open three PNGs by hand - the baseline, the new screenshot, and the diff - then decide, and if you re-run the suite you do the whole loop again. With UI Verify the diff is already on the pull request: a person accepts or rejects it in the review UI, and a coding agent reads the cropped before-and-after over MCP and accepts the intended baselines without ever leaving the pull request. Nobody downloads a zip.

• You have a handful of screenshots and are happy to review the diffs yourself.
• You already run Playwright and want the visual check to gate entirely inside your own CI.
• You do not need hosted history, a review UI, or an AI judge triaging each change.
• You are not working with coding agents that review visual diffs and accept baselines over MCP.

For a small suite you review yourself, yes - it is free, local, and built in. It starts to strain when the baselines multiply: every screenshot is a PNG or WebP committed to your repo, cross-OS differences push you into a pinned Docker image, and a change is a failed test with no history or review UI. That is the point where a hosted tool earns its keep.

No. UI Verify stores baselines in the service, one per branch and resolved from your git history, so there are no screenshot images in your repo and no per-OS baseline files to maintain.