Send two page states, let Snapshot Site normalize the renders, and receive before, after, and diff images with mismatch metrics. Use the result in QA gates, release reviews, monitoring, and visual approval workflows.
POST /api/v3/compare
Capture or load two controlled states, normalize them into the same canvas, and return a diff image plus mismatch statistics for automated triage and human review.
Use live URLs when you want Snapshot Site to render both pages, or provide existing PNG screenshots when you already have captures in storage.
The engine aligns both images on the same canvas, then highlights changed pixels in a dedicated diff image with a configurable sensitivity threshold.
Store the three image URLs, surface mismatch percentage in CI, or send the diff link to product, QA, or growth teams for approval.
{
"before": {
"url": "https://snapshot-site.com/pricing",
"width": 1440,
"fullSize": true,
"hideCookie": true
},
"after": {
"url": "https://staging.snapshot-site.com/pricing",
"width": 1440,
"fullSize": true,
"hideCookie": true
},
"threshold": 0.1
}
{
"status": "success",
"message": "Visual diff successfully created!",
"fetchTime": "ISO_8601_TIMESTAMP",
"before": {
"link": "https://api.prod.ss.snapshot-site.com/screenshots/snapshot-site.com/uuid-1/1.png",
"width": 1440,
"height": 3980,
"source": "https://snapshot-site.com/pricing"
},
"after": {
"link": "https://api.prod.ss.snapshot-site.com/screenshots/staging.snapshot-site.com/uuid-2/2.png",
"width": 1440,
"height": 3980,
"source": "https://staging.snapshot-site.com/pricing"
},
"diff": {
"link": "https://api.prod.ss.snapshot-site.com/screenshots/comparisons/uuid-3/3.png",
"width": 1440,
"height": 3980
},
"summary": {
"mismatchPixels": 14382,
"mismatchPercentage": 1.27,
"totalPixels": 5731200,
"sameDimensions": true
}
}
The first release is already useful because it solves one painful question clearly: what changed between version A and version B?
A SaaS team compares key pages before every deploy to catch layout shifts, missing components, or regression bugs before customer traffic sees them.
A performance marketing team validates hero copy swaps, pricing card edits, and CTA changes before turning paid campaigns back on.
A compliance or archive workflow snapshots the same page regularly and uses the diff output to highlight exactly what changed since the previous capture.
Visual regression testing checks whether a new page state looks different from an approved reference. Functional tests can confirm that a component exists or a button responds; they may not notice that the component moved outside its container, inherited the wrong font, overlapped another block, or disappeared behind a responsive breakpoint.
A visual test turns both states into images and compares their pixels. Snapshot Site's POST /api/v3/compare endpoint accepts two sources, creates or loads the captures, normalizes them, and returns a third diff image that marks changed regions. Mismatch metrics provide a compact signal for automation, while the diff image gives a reviewer the context required to decide whether the change is expected.
A mismatch percentage answers “how many pixels changed?” It does not answer “is the product broken?” A corrected typo, an approved campaign banner, and a collapsed pricing grid can all change pixels. The meaning depends on the page and the release.
Use mismatch data to route work:
Do not copy one threshold across every page. A documentation article and an application dashboard have different visual behavior. Establish thresholds from real runs on the pages your team owns.
Both states should use the same width, full-page mode, cookie handling, delay, and hidden selectors. Changing the width can trigger another responsive layout. Changing the delay can capture different animation frames or asynchronous content. These are capture differences, not regressions.
For long pages, use full-page screenshots on both sources. For mobile checks, use the same mobile width and height for the reference and candidate.
Timestamps, animated carousels, random recommendations, live counters, ads, and personalized content can change while the application remains healthy. If the page belongs to your team, provide deterministic test data and disable animations in the preview environment. If the page is external, use stable selectors to remove only the transient regions that are irrelevant to the review.
Avoid masking the area where a real bug is likely to occur. Every excluded region reduces false positives and also reduces coverage.
The baseline should represent an approved visual state. Replace it only after a reviewer accepts an intentional change. If every successful deployment silently becomes the new baseline, a regression can be approved by the same automation intended to detect it.
Store the baseline identifier and capture settings with the test definition. A future reviewer should be able to explain which reference was used and how both images were produced.
Deploy the branch to a preview URL, compare critical routes against production, and attach the diff links to the pull request. Start with a small route set—login, dashboard, pricing, checkout, and other high-risk pages—before expanding coverage. The screenshot automation page describes CI and scheduled trigger patterns.
Growth changes often involve copy, assets, spacing, and calls to action. A visual diff gives marketing and product teams one artifact that shows what moved. Compare both desktop and mobile layouts because a change approved at one width can break another.
A monitoring workflow compares a live page with a stored known-good image on a schedule. The same diff endpoint is used, but the trigger and response differ: CI protects a release, while website monitoring protects a page after release.
Before, after, and diff images provide a visual history for pages where content changes matter. They support investigation and review, but they do not replace source records, accessibility checks, or legal retention requirements.
DOM tests and visual tests answer different questions. A DOM assertion is precise when the expected property is known: a heading exists, an attribute has a value, or an element is visible. A visual comparison is broad: it can detect an unexpected effect without knowing which selector caused it.
Use DOM and functional tests for business rules and interactions. Use visual regression tests for composition, styling, responsive behavior, and rendered content. When a diff fails, use the image to locate the region and application diagnostics to find the cause.
Store the Snapshot Site key in the CI secret manager, not in repository files or preview-page JavaScript. Sanitize logged URLs when they contain tokens or private query values. Restrict who can approve a new baseline on sensitive routes.
Treat failed comparisons as normal job states. Preserve the before, after, and diff references needed for debugging. Apply bounded retries only to transient capture failures; retrying a real mismatch will not make the regression disappear.
Start with one stable route and one controlled change. Once the team trusts the signal, expand to the pages and breakpoints where visual defects create the most risk.
Visual regression testing compares a known page state with a new one to find pixel-level changes. It complements functional tests by detecting layout shifts, missing content, styling changes, and other visible regressions.
The compare endpoint returns before, after, and diff image information together with mismatch metrics such as changed pixels, mismatch percentage, total pixels, and whether dimensions match.
Yes. Provide the two live URLs with identical viewport and capture settings. The API renders both states, normalizes the images, and produces the comparison result.
Yes. A comparison source can use an existing image URL when you already store a known-good baseline, while the other source can be a newly rendered live page.
Start by measuring several intentional and unintentional changes in your own pages. Use the threshold as a triage signal, then inspect the diff image before automatically blocking a release.
Keep width, full-page mode, timing, cookie handling, and hidden selectors identical. Stabilize animations, rotating content, timestamps, and other dynamic regions when possible.
No. A visual comparison cannot prove that interactions, accessibility, network requests, or business logic work. Use it alongside functional, semantic, and accessibility tests.
Yes. Call the compare endpoint after a preview deploy, record mismatch information in the job, and attach the diff image to the pull request or release review.
Capture two controlled page states, inspect the diff image, and decide which changes need review.