Overview
Catch the change you did not mean to make. Visual photographs your screens, compares each one with the version you approved, and shows you exactly what moved.
Visual takes a picture of a screen, compares it with the picture you approved last time, and shows you the difference.
That is the whole idea. A test suite tells you a button still works. Visual tells you the button moved forty pixels, changed colour, or vanished behind a banner — the kind of change no assertion was ever written for, and that nobody notices until a customer does.
Key capabilities
Three ways to capture
From a Live session you are already driving, from a list of page addresses we open for you, or from your own test suite's screenshots.
Pixel comparison
Every picture is compared with its approved baseline. You see the two side by side and the difference highlighted.
Three states, no more
Approved, unreviewed, or reported as a bug. A screen is always in exactly one of them.
Ignore regions
Draw a box over a clock, a carousel, or an advert and it stops counting as a difference.
Works with any framework
Playwright, Cypress, Puppeteer, Selenium — a folder of PNGs is not a framework.
File it where you work
Report a difference straight to GitHub, Jira, GitLab and others, with the screenshot attached.
How a comparison works
The first time Visual sees a screen, there is nothing to compare it with, so that picture becomes the baseline — the approved version.
Every time after that, the new picture is compared with the baseline:
- Identical — nothing to do.
- Different — it waits for you. You either approve it (it becomes the new baseline) or report it as a bug.
A screen is matched to its baseline by its name, the browser and operating system it was taken on, and the width it was taken at. Change the width and you get a separate baseline, which is what you want — a mobile layout and a desktop layout are different screens.
Height is deliberately not part of that match. A full-page screenshot is as tall as the page, so a page that grows a row taller is still the same screen — it is a change to review, not a brand-new screen.
Where the pictures come from
| Source | Best for | What you need |
|---|---|---|
| A Live session | Checking a screen while you are already looking at it | A Live session |
| A list of addresses | Public pages, checked on a schedule | Nothing — Visual opens the browser |
| Your own test suite | Anything behind a login, a component library, a flow | Your tests, and our CLI in CI |
The third is the one most teams end up living on, because your tests have already signed in, filled the basket and opened the modal. See Uploading from CI.
Visual and the rest of TestKase
Visual is its own subscription. It does not consume Live or Automate minutes — uploading and comparing pictures never starts a session, so nothing is billed against those plans.
Capturing from inside a Live session uses that Live session as normal. The session is what costs, not the picture.
FAQ
▶How is this different from a screenshot test in my own suite?
A screenshot assertion in your suite compares against a file in your repository, so every legitimate change means committing new image files and arguing about them in a pull request. Visual keeps the approved versions for you, shows you the difference, and asks a person to decide — and it keeps the history, so you can see when a screen last changed and who approved it.
▶What counts as different?
Any pixel that differs, above a threshold you control per project. Anti-aliasing and tiny rendering wobble are already tolerated; the threshold is there for pages with genuinely noisy content. If one part of the screen is always in motion, draw an ignore region over it instead of raising the threshold for everything.
▶Do I have to approve every change by hand?
Yes, and that is the point. An automatic approval is indistinguishable from not checking. What you can do is narrow what gets flagged — ignore regions for the clock and the carousel, a threshold for pages that never render identically twice.