Visual testing on Netlify deploy previews is the automatic execution of a visual comparison between a site deployed in preview by Netlify (generated for each pull request or branch) and a production reference, in order to detect any display regression before the merge, using the unique preview URL as the testing surface.
Netlify was one of the pioneers of the deploy preview. Long before this feature became an industry standard, Netlify already offered a preview URL for each pull request. It has become such a natural part of the workflow that most teams can no longer imagine working without it.
And yet, the vast majority of these teams use deploy previews as a simple consultation tool. They deploy, take a quick look, and merge. It's exactly like driving while only looking ahead — you see where you're going, but you don't see what you're leaving behind.
Our position: Netlify deploy previews without automated visual testing are like driving without a rearview mirror. You have the road ahead of you (the feature works), but you have no visibility into the potential damage your changes are causing across the rest of your site. You hope nothing has shifted. Hope is not a quality strategy.
Netlify Deploy Previews: Untapped Potential
Netlify deploy previews are a remarkable feature. Every pull request, every branch, automatically generates a complete site deployed to a unique URL like deploy-preview-42--your-site.netlify.app.
This is not a local development server. It's a full deployment, on Netlify infrastructure, with the CDN, redirects, headers, forms, serverless functions — everything. The preview site is functionally identical to production.
Netlify goes even further with features specific to previews.
Deploy contexts. Netlify allows configuring different behaviors depending on the deployment context (production, deploy-preview, branch-deploy). Your environment variables, redirects, and headers can vary between production and preview. This is powerful, but it's also a potential source of visual differences that only automated testing can detect.
Deployment notifications. Netlify offers a notification system (webhooks, Slack, email) that triggers at each deployment stage. Visual testing can hook into these notifications to launch automatically as soon as the preview is ready.
Deploy locking. Netlify allows locking a deployment to prevent automatic updates. This is useful for freezing a reference version while visual testing runs.
All these features serve a smooth and reliable visual testing workflow. But today, most teams only use them for manual consultation.
The True Cost of Manual Verification
Let's analyze what manual verification of deploy previews truly costs.
The time cost. Imagine a project with twenty key pages, tested on two viewports (desktop and mobile). Manually verifying each page on each viewport takes an average of one minute — being optimistic. That's forty minutes of verification for each PR. On a project with five PRs per day, that's over three hours daily dedicated to visual verification. In practice, nobody does that. You check two or three pages and move on.
The reliability cost. Manual verification is subject to fatigue, cognitive biases, and deadline pressure. "We'll ship tomorrow, the visual review looks fine, it seems correct." This sentence has caused more visual regressions in production than all CSS bugs combined. Visual regressions that escape manual review erode user trust over time.
The responsiveness cost. A visual regression detected manually in production requires a complete correction cycle: identify the offending commit, create a hotfix, test, deploy. If the same regression is automatically detected on the deploy preview, it's fixed before the merge, within the normal development flow. The correction cost is ten times lower.
The confidence cost. A team that regularly ships visual regressions to production loses the trust of its users, its clients, and its own management. Automated visual testing isn't just a technical tool. It's a reputation protection mechanism.
How to Automate Visual Testing on Deploy Previews
Automation follows a four-step flow, each leveraging Netlify's native capabilities.
Triggering via Webhook or Notification
Netlify allows configuring webhooks that trigger on specific events: deploy started, deploy succeeded, deploy failed. The "deploy succeeded" webhook is the one we're interested in. It signals that the preview is ready and accessible.
The webhook payload contains all the necessary information: the deploy preview URL, the branch name, the commit SHA, the deployment context. The visual testing service receives this webhook and launches a capture session.
The alternative to webhooks is to use the Netlify API for polling the deployment status. But the webhook is preferable: it's event-driven, instantaneous, and doesn't consume resources in active waiting.
Capturing on the Netlify Preview URL
Once the webhook is received, a headless browser navigates to each configured page on the Netlify preview URL. The capture follows the usual visual testing best practices.
Wait for full loading. Sites deployed on Netlify often use a CDN that serves assets asynchronously. You must wait for all resources (images, fonts, scripts) to load before capturing.
Stabilize the rendering. Disable CSS animations, mask dynamic elements (timestamps, counters, personalized content), freeze carousels and sliders.
Capture in multiple viewports. Desktop, tablet, mobile. Sites deployed on Netlify are often JAMstack sites or static applications with responsive design. Responsive regressions are frequent and impactful. Cross-browser visual testing is essential to cover all viewport combinations.
Handle Single Page Applications (SPA). If your site is a SPA, navigation between pages happens client-side. The headless browser must simulate this navigation and wait for complete rendering of each route before capturing. For more on visual testing in CI/CD pipelines, see our guide.
Comparison with Production or References
The deploy preview screenshots are compared to a baseline. Two reference strategies are possible.
Comparison with live production. Visual testing simultaneously captures the production site (your-site.netlify.app or your custom domain) and the deploy preview, then compares the two sets of screenshots. The advantage is that the reference is always up to date. The disadvantage is that intentional changes are always flagged as differences.
Comparison with validated references. Visual testing compares the deploy preview screenshots to a set of reference captures validated by the team. The advantage is that only unintentional changes are flagged. The disadvantage is that references must be updated when intentional changes are merged.
In practice, the second approach is preferable for projects in active development. The first is useful for sites in maintenance mode where every visual change must be scrutinized.
Reporting Integrated into the Pull Request
Results are reported on the pull request via an automatic comment and a status check.
The comment includes a clear summary: number of pages verified, number of pages with differences, preview of the most significant diffs, and a link to the full report.
The status check (green or red) conditions the merge. If unapproved differences exist, the merge is blocked. The developer must review the diffs, validate or fix, then rerun the test.
This flow is natural. It integrates into the existing work cadence without adding significant friction.
Netlify's Specific Strengths for Visual Testing
Netlify has characteristics that make it particularly suited for automated visual testing.
Deploy preview stability
Netlify deploy previews are immutable. Once deployed, a preview doesn't change — even if a new commit is pushed to the branch (a new preview is created instead). This immutability is crucial for visual testing: you have the guarantee that the site won't change between the start and end of capture.
CDN and performance
Deploy previews are served via the Netlify CDN, exactly like production. Loading times are realistic, images are optimized, assets are compressed. The captured screenshots are representative of the actual rendering.
Forms and serverless functions
Netlify handles forms and serverless functions even in deploy previews. If your site has a contact form or a shopping cart powered by a function, they work in the preview. Visual testing captures a complete rendering, not a degraded version.
Split testing (A/B testing)
Netlify offers native split testing. If you're testing two variants of a page, visual testing can capture both variants and compare them to their respective references. This is a level of coverage that few visual testing workflows achieve.
Header and redirect management
Deploy previews respect the header and redirect configurations defined in netlify.toml or the _headers file. This means visual testing captures the site with the same caching, CSP, and redirect rules as production.
Scenarios Where Visual Testing Saves the Day
Static site generator update
Gatsby, Hugo, Eleventy, Astro — every major framework update can modify the rendering in subtle ways. A change in the Markdown parser, an image processing update, a modification of generated HTML. The deploy preview is there. Visual testing verifies the rendering is identical. If a page is affected, you know before merging the update.
CDN or Netlify configuration change
Modifying the netlify.toml configuration (redirects, headers, build commands) can have unexpected visual effects. A misconfigured redirect can serve the wrong page. An overly restrictive CSP header can block web font loading. Visual testing detects these visual consequences.
Content addition by a non-developer
If your site uses a headless CMS (Contentful, Sanity, Strapi) connected to Netlify via a build webhook, adding content by an editor triggers a new build and a new deploy preview. Visual testing verifies that new content displays correctly, that images are at the right dimensions, that text doesn't overflow its container.
Migration to a new design system
Replacing Bootstrap with Tailwind, migrating from CSS Modules to styled-components, or adopting a new design system — these migrations are minefields for visual regressions. Visual testing on each deploy preview transforms an anxiety-inducing migration into a controlled one, page by page, component by component.
External contributions (open source)
If your site is open source and accepts external contributions, deploy previews combined with visual testing are an indispensable protection layer. An external contributor can introduce unintentional visual changes. Visual testing flags them automatically, without the maintainer having to inspect each page manually.
The No-Code Approach for Netlify
Implementing a complete visual testing workflow on Netlify — webhooks, headless browser, comparison, reporting — represents significant work if you start from scratch. This is precisely the type of complexity that a no-code tool like Delta-QA eliminates.
Setup takes just a few steps. You connect your Netlify site to Delta-QA. You select the pages to monitor in a visual interface. You configure the viewports. Delta-QA automatically registers as a webhook on your Netlify site.
From there, every deploy preview automatically triggers a visual testing session. Results appear on your pull request. Diffs are clear and actionable. Approvals of intentional changes happen with a single click.
The goal is for visual testing to be as invisible and automatic as the deploy preview itself. You don't think about deployment when you open a PR on Netlify — it happens by itself. Visual testing should work the same way. No scripts to maintain. No configurations to adjust. Just results, on every PR, automatically.
Frequently Asked Questions
Are Netlify deploy previews accessible to visual testing tools?
By default, yes. Netlify deploy previews are publicly accessible via their unique URL. However, if you've enabled password protection (Site protection in Netlify settings), the visual testing tool will need to authenticate. With Delta-QA, you configure credentials once and authentication is handled automatically on every capture.
How many Netlify deploy previews can exist simultaneously?
Netlify doesn't limit the number of active deploy previews. Each PR and each branch generates its own preview. This is advantageous for visual testing because it means every change is independently testable. However, if you have many open PRs, make sure your visual testing tool properly handles concurrent capture sessions.
Does visual testing work with Netlify sites using serverless functions?
Yes. Serverless functions (Netlify Functions) are active in deploy previews. If your site uses functions for dynamic rendering, APIs, or personalization, the deploy preview reflects this behavior. Visual testing captures the final result as the user sees it, including content generated by functions.
How to handle differences between deploy contexts (production vs deploy-preview)?
If your netlify.toml defines different environment variables or configurations for the deploy-preview context, the preview rendering may differ slightly from production. For example, a "Preview" banner or disabled analytics. Configure your visual testing tool to mask these expected differences, or create references specific to the deploy-preview context.
Does visual testing detect issues related to Netlify forms?
Visual testing detects form display issues: a mispositioned field, an invisible button, a label overlapping an input. However, it does not test the functional behavior of the form (submission, server-side validation). For that, complementary functional tests are needed. Visual testing and functional tests are two distinct and complementary layers.
Can visual testing be used on branch deploys in addition to deploy previews?
Absolutely. Netlify distinguishes deploy previews (linked to a PR) from branch deploys (linked to a branch without a PR). Visual testing can run on both. Branch deploys are particularly useful for long-lived branches (develop, staging) that aren't systematically associated with pull requests. Monitor them visually to detect accumulated drift.
Conclusion
Netlify deploy previews are a gift that too many teams waste. You have, for free, a complete and accessible deployment of every modification before the merge. It's an open window into the future of your site. And most of the time, nobody looks through that window systematically.
Automated visual testing transforms this window into a sentinel. Every deploy preview is captured, compared, analyzed. Regressions are flagged before they reach production. Intentional changes are documented and approved. The visual history of your site is built automatically.
Driving without a rearview mirror means counting on luck to not cause an accident. Deploying without visual testing means counting on luck to not break your site's appearance. In both cases, luck always runs out eventually.
A tool like Delta-QA makes installing this rearview mirror trivial. A few minutes of configuration, and every Netlify deploy preview is automatically visually verified. Your site is protected. Your users see what they should see. And you can merge with confidence.
It's time to install that rearview mirror.