When you ask developers about testing, they usually mean one of two things: a human clicking through pages to verify nothing broke, or a suite of automated unit and functional tests running in a CI pipeline. Manual or automated. Simple enough.
Visual regression testing doesn’t fit neatly into either category — and that’s the point.
It automates the manual steps of opening pages and checking that they look right, without going into the granular functional detail of asserting return values and API responses. It can be run by non-technical people. It covers the whole page, not just the code. That middle ground is where it gets really valuable.
When Does Visual Regression Testing Make Sense?
Before reaching for any tool, it helps to know which problems it actually solves. A few use cases come up again and again.
Code Changes and Dependency Updates
Running Drupal updates? Pulling changes from an upstream theme? Migrating between Bootstrap versions where class names changed? These are exactly the moments when something that worked last week quietly breaks. A visual regression run before and after the deployment gives you proof — or an early warning.
Data Migrations
If you are migrating a site with hundreds of pages, there is no way to manually verify each one. But you can take screenshots before deploying each migration batch and compare them afterward. Did that block appear on the pages you expected? Did images migrate correctly? Did one migration accidentally break a component that had nothing to do with what you changed? A crawler that screenshots every page answers all of those questions.
Ongoing Visual Monitoring
For sites with active editorial teams or frequent deployments, scheduled screenshot runs give you a visual history — your own version of the Wayback Machine. If something breaks, you can trace it back to a specific date. Combined with content revisions in your CMS, you can see exactly when and why a change was made.
Compliance and Content Review
Certain industries — legal, pharmaceutical, and others with strict editorial processes — require detailed reviews before pushing changes to production. Rather than having reviewers navigate through a staging environment, teams can take screenshots of every changed page, annotate them, and sign off on a PDF-like record. Tools like Diffy let you download a full screenshot set in one go, making this kind of audit workflow much more manageable.
The Two Extremes to Avoid
There are two failure modes in testing strategy, and both are common.
The first is doing nothing. Every project starts there. But when people skip testing consistently, bugs accumulate and the connection between a deployment and a regression gets harder and harder to trace. Corners get cut — “we only changed this one section, so we only tested this one section” — until something breaks on a page nobody thought to check.
The second is trying to test everything. Full coverage of every piece of functionality on a large site is theoretically ideal and practically punishing. It is expensive to build, expensive to maintain, and with today’s pace of iteration, it will slow your team down significantly.
The approach that actually works is somewhere in the middle. The Drupal core project is a good model: when automated testing was introduced, nobody stopped development to achieve 100% coverage. The rule was simple — everything new or changed needs a test; everything already working is assumed to be working. Coverage expanded gradually, and stability improved over time.
Start with the easy wins. If you spend 15 minutes checking 10 pages every time you deploy, automate those 10 pages. You have already saved yourself 15 minutes per release, and you can build from there.
Signs You Need Visual Regression Testing
Some projects benefit from it more than others. A few warning signs worth paying attention to:
The site has changed hands multiple times. An older website that has passed through three or four agencies accumulates complexity. CSS files grow to thousands of lines. Relationships between components become hard to predict. A change in one place has unexpected effects somewhere else. This is where visual regression testing pays for itself fastest.
You have multiple theme layers. A base theme, a university-level style guide, a child theme built from that — changes flow down through all of them. An update to the base theme can silently affect your customizations in ways you don’t catch until a user reports something.
You have a lot of overrides. The more you diverge from upstream defaults, the more isolated you are. More isolation means more surface area for things to break in unexpected ways.
Choosing What to Test
A common question when starting out: which pages do you actually add to your test suite?
Two approaches work well. If you know your site well, start with coverage of unique layouts — one or two pages of each content type, key landing pages, anything that is visually distinct from the rest. You do not need to test every article; you need to test the template.
If you are less familiar with the site, open your analytics and find the top 20 pages by traffic. Something breaking on a page that nobody visits is unfortunate. Something breaking on page 10 of your traffic ranking is a problem.
The same logic applies to breakpoints. Cover the viewport widths where your layout actually changes, and check your analytics to see what devices your visitors actually use.
One useful pattern from the community: build a style guide page (or a small set of them) that assembles all your component types — blocks, paragraphs, cards, whatever building blocks your system uses. Keep it hidden from visitors. If you test those pages on every deployment, you can assert that your component library is intact before you ever check a real content page.
Why Taking Good Screenshots Is Harder Than It Sounds
The idea of taking a screenshot seems trivial. In practice, it is not.
Modern websites have sticky headers that overlap content, lazy-loaded images that have not rendered yet, cookie popups that obscure the page, carousels mid-animation, maps that change their tile layer between runs, and dynamic phone numbers swapped by campaign tracking scripts. Take a screenshot of any of these without handling them first and you get noise, not signal.
There are also technical tradeoffs just in how you capture a full page. Opening a very tall browser viewport captures everything in one shot but can stretch elements whose height is set relative to the viewport. Stitching together multiple smaller viewport captures avoids that problem but puts sticky headers on every segment. Diffy uses a tall browser combined with JavaScript that walks the DOM looking for percentage-based and viewport-unit heights and overrides them — it catches most cases, but some still need manual CSS rules.
The practical checklist for any visual regression tool you evaluate:
- Delay before capture — time for assets and fonts to finish loading
- Page scroll — trigger lazy loading before the screenshot
- Element removal — hide cookie popups and overlays
- Element masking — ignore areas like maps that change on every run
- JavaScript injection — freeze carousels, pause videos, replace dynamic copy with placeholder text
- CSS injection — override height properties on tall elements
- Cookie and header control — simulate logged-in states or dismiss popups that store preferences
- Login support — cover admin and authenticated experiences, not just public pages
- CDN bypass — route screenshots through a fixed IP if your CDN blocks cloud traffic
- Concurrency control — 30 parallel browsers against a dev environment will take it down
What Makes Diffy Different
Most visual regression tools compare images pixel by pixel and flag any difference. That works fine for simple pages, but on a real website it means a change in the header — a new navigation item, a banner — shifts everything below it down by a few pixels and flags the entire page as changed. The diff is technically accurate and completely useless for review.
Diffy’s comparison algorithm recognizes vertical shifts. It can distinguish between “something moved because content above it changed” and “something is actually different here.” You can switch to pixel-perfect mode if you want it, but the default view groups related changes and makes the signal-to-noise ratio much better.
A few other things worth knowing:
- Thumbnail review — you can triage a comparison set from thumbnails before drilling into individual pages, which makes approving routine deployments fast
- Same-change grouping — if a header change appears on 30 pages, you can mark all 30 as expected (or as a bug) in one step rather than clicking through each one
- Shareable links — cloud-hosted results mean you can drop a link in a Jira ticket for your QA team without them needing a Diffy login
- CLI tool — four lines of shell script is enough to add visual regression to a pull request pipeline that uses Tugboat, Pantheon multidev, or any environment-per-PR setup
- Local development — a Docker container lets you take screenshots against localhost and upload them for comparison, so you can check your own branch before opening a PR
- Figma comparison — export designs and compare them directly against your staging environment
- Playwright integration — if you already take screenshots at points in your functional test suite, you can upload those to Diffy and use the same comparison workflow
Diffy has a free tier. If you have a project you want to try it on, reach out via Intercom and we will help you get the configuration right so your first run does not drown in false positives.
A Note on AI
Every talk about testing in 2026 needs to address AI, so here it is honestly.
AI is genuinely useful for describing changes between screenshots. If a whole section disappeared or a headline changed, it can tell you that clearly and quickly. What it cannot do yet is reliably detect small shifts — a few pixels of padding, an element that moved slightly. Visual regression testing is still fundamentally visual, and humans are still better at the judgment call of “is this a bug or an expected change.”
What we are working toward at Diffy is using AI to summarize a comparison run. When you have 100 pages and many changes across them, the goal is for the system to tell you: “there is a recurring change on these five pages” and “here are ten instances of this other change.” A summary, not a verdict. That is where AI fits into this workflow, and it is on the roadmap.
Wrapping Up
Visual regression testing is not a replacement for functional testing, and it is not a replacement for manual QA. It is the thing in between — fast enough to run on every deployment, broad enough to catch what unit tests miss, and accessible enough that a project manager can do the review.
Start small. Pick the pages you check manually today and automate them. Add more as your confidence and your test suite grow. The point is not to test everything — the point is to stop discovering regressions from users.