How to Create a Side-by-Side Website Screenshot Comparison for a Design Review

To create a useful side-by-side website screenshot comparison, capture the same route in the old and proposed versions with the same browser, viewport, zoom, scroll position, and page state. Put the equal-sized captures next to each other, label each version, and note the capture conditions. For a one-off design review, that manual pair is usually enough. For recurring reviews, use screenshot baselines with Playwright or a hosted visual-review workflow such as Percy.

A side-by-side comparison is a review aid, not an objective verdict on design quality. Matching capture conditions helps reviewers distinguish intended design changes from differences caused by the browser, operating system, timing, or page content.

1. Choose the comparison workflow

Workflow	Best fit	What it gives you
Manual screenshots	One-off critique, stakeholder review, or presentation	Two labeled images arranged at the same size
Playwright snapshots	Repeatable checks alongside application code	Screenshot assertions against expected snapshots
Percy	Team review of recurring visual changes across browsers or widths	Snapshots compared with approved baselines and review views

Playwright Test supports page and element screenshot assertions against expected snapshots. Its snapshot images are PNG by default; its documentation recommends keeping the snapshot directory in version control and reviewing changes. Percy captures screenshots and compares them with approved baselines, and can be configured for browser and responsive-width coverage. See the official guides for Playwright visual comparisons and BrowserStack Percy visual testing.

2. Make the captures comparable

1. Use the same page. Capture the exact route in both versions, including the same query parameters if they affect the page.
2. Match the rendering setup. Keep browser, browser version, operating system, viewport width and height, device scale, and zoom consistent. Browser rendering can vary with the host OS, version, settings, hardware, power source, and headless mode, among other factors. See Playwright’s visual comparison guidance.
3. Match page state. Use the same scroll position, interaction state, account or fixture data, locale, and consent state. If a menu, modal, or hover state is under review, reproduce that state in both captures.
4. Wait for stable content. Allow fonts and images to load. Avoid capturing while animations are moving or while timestamps, rotating banners, ads, or other changing content differ. Where possible, use stable test data and disable animation for the review capture.
5. Choose the capture area. Use a viewport capture when reviewing a screen-sized composition. Use full-page captures when the review includes content below the fold, and use the same full-page behavior in both versions.

Cross-browser work needs special care: fonts, form controls, and scrollbars can differ by operating system and appear in a visual diff. BrowserStack documents these sources of variation in its cross-browser visual testing guidance.

3. Build a one-off side-by-side review

1. Capture the old version and proposed version at the same route and under the same conditions.
2. Check that the files have matching dimensions. If they do not, recapture with matching settings where possible; resizing can conceal a layout mismatch.
3. Place the old version on the left and the proposed version on the right in an image editor, slide, or document. Display both at the same size.
4. Add short labels, such as “Current” and “Proposed,” plus the route, viewport, browser, and capture date.
5. Ask reviewers to comment on specific regions and intended changes. A difference in every pixel is not equally meaningful.

For a focused review, compare one viewport at a time. If responsive behavior matters, make a separate matched pair for each target width and label each pair. Keep the original screenshots available so reviewers can inspect details at full resolution.

4. Repeat the comparison with Playwright

This example uses Playwright Test in TypeScript. It captures one route and compares the result with an approved screenshot snapshot. Set the base URL through an environment variable so the same test can target the old or proposed build. Run the two builds in the same browser and environment, and keep separate baseline sets if both versions need to be reviewed independently.

import { test, expect } from '@playwright/test';

test('homepage matches the approved visual snapshot', async ({ page }) => {
  await page.setViewportSize({ width: 1440, height: 900 });
  await page.goto(`${process.env.BASE_URL}/`, { waitUntil: 'networkidle' });
  await page.evaluate(() => document.fonts.ready);
  await expect(page).toHaveScreenshot('homepage.png', {
    fullPage: false,
    animations: 'disabled',
  });
});

Install Playwright Test and its browser using the official Playwright installation instructions. Save the test as tests/homepage.visual.spec.ts. Set BASE_URL to the version you want to capture, then run:

BASE_URL=https://your-preview.example npx playwright test tests/homepage.visual.spec.ts

To create or update expected snapshots intentionally, use the update option:

BASE_URL=https://your-preview.example npx playwright test tests/homepage.visual.spec.ts --update-snapshots

Review updated PNGs before accepting them. Store snapshots with the project in version control so changes have a reviewable history. Keep the capture environment stable; a baseline produced on a different OS, browser version, or rendering mode can create noise. For a specific component, use an element screenshot assertion instead of a full page assertion:

const card = page.locator('[data-testid="pricing-card"]');
await expect(card).toHaveScreenshot('pricing-card.png');

Playwright options that affect screenshot comparisons

• fullPage: captures the whole page instead of the visible viewport.
• animations: disabling animations reduces mismatches from moving content.
• mask: masks elements with dynamic content, such as a changing avatar or timestamp; use it only when that content is outside the review scope.
• maxDiffPixelRatio and threshold: control pixel comparison tolerance. Keep tolerances tight enough to catch meaningful changes, and investigate differences before relaxing them.
• stylePath: applies a stylesheet during capture, which can hide unstable elements or normalize the review state when appropriate.

Consult the Playwright screenshot assertion documentation for current option details. A larger tolerance can suppress benign rendering noise, but it can also hide real regressions.

5. Review snapshots with Percy

Percy is a hosted visual-testing workflow: capture snapshots, compare them against approved baselines, and review the changes. It is useful when a team needs browser or responsive-width coverage and a shared review process. Configure the project to capture the route and widths relevant to the design review, then inspect the resulting snapshots. BrowserStack describes side-by-side, overlay, and diff views in its visual analysis guide.

In the review, select the snapshot and inspect the intended browser and width. Use side-by-side view to compare overall composition, overlay to check alignment, and diff view to locate changed regions. These views help surface changes; they do not establish that a design is correct.

Percy usage and plan terms can change. Screenshot usage depends on the selected browser and responsive-width combinations, so check the current Percy plans and billing documentation before estimating cost.

6. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. A single request captures a URL as PNG, JPEG, WebP, or PDF. For a fair before-and-after comparison, call it once for each version using the same capture settings. See the ScreenshotNeo API documentation for parameters.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Replace the example URL with the old or proposed page URL, and use the same options for both captures. ScreenshotNeo can remove cookie banners, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server offers take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots.

Sign up free for 1,000 screenshots a month, with no card.

7. Troubleshooting visual mismatches

Symptom	Likely cause	Fix
Large diff across the whole page	Different viewport, browser, OS, device scale, or baseline environment	Match the capture environment and dimensions, then recapture before changing thresholds.
Text wraps differently	Font did not load, font version differs, or viewport width changed	Wait for document.fonts.ready, verify the same font assets are available, and match the viewport.
Images appear blank or incomplete	Capture happened before image loading or lazy-loaded content entered view	Wait for relevant images, scroll through lazy-loaded sections when capturing full pages, and confirm both builds return the assets.
Only timestamps, ads, or rotating content differ	Dynamic content changed between captures	Use deterministic fixtures, freeze time where possible, or mask only the unstable region that is outside the review.
Controls differ between machines	OS-specific form controls, fonts, or scrollbars	Use the same OS and browser for design review, or intentionally compare separate browser/OS configurations.
Playwright reports a missing snapshot	No baseline exists for that test and environment	Generate a baseline deliberately with --update-snapshots, then inspect and commit the image.
Snapshot changes after a dependency update	Browser or rendering version changed	Check the browser and dependency update, regenerate snapshots in the standard environment, and review the differences.
Comparison looks scaled or blurry	Images have different pixel dimensions or were displayed at different sizes	Capture matching dimensions and compare at the same display scale.

8. Performance, reliability, and cost

• Manual review: fastest to set up for a single page. The main cost is reviewer time; capture conditions and labels make the result easier to reproduce.
• Playwright: adds browser execution and snapshot maintenance to the project workflow. Stable environments and focused assertions reduce noisy review work. Snapshot updates should be reviewed as code changes.
• Percy: provides hosted review and configured browser/width coverage. More browser and responsive-width combinations affect screenshot usage; verify current plan terms before budgeting.
• Any approach: full-page captures and many viewport configurations require more capture and review effort than a focused viewport. Keep the scope aligned with the design question.

Visual results are only as reliable as the input state. Keep data, browser version, fonts, timing, and viewport consistent; document any unavoidable differences. A pixel diff is evidence of a rendered change, not proof that the change is a defect.

Frequently asked questions

Should the old design go on the left or right?

Put the current or old version on the left and the proposed version on the right, and label both clearly. Consistency helps reviewers scan multiple comparisons.

Should I use a full-page screenshot?

Use one when the review covers the entire page or below-the-fold content. For spacing and composition within a specific screen, a matched viewport capture is often easier to inspect.

Can a visual diff decide whether a design is good?

No. It shows rendered differences. Reviewers still need to judge whether each difference is intended and meets the design goals.

Can I compare pages captured on different operating systems?

You can, but OS rendering can change fonts, controls, and scrollbars. For a design-change review, use one environment; for cross-browser coverage, treat each browser and OS as its own comparison target.