Cross-Browser Testing Checklist Before Launching a Website

Before launch, choose browser and device targets from your audience and project requirements, then verify that the site’s important tasks, layout, and accessibility work on each target. No team can realistically test every browser and device combination, and the goal is a usable, reliable experience—not pixel-identical rendering everywhere.

Use this checklist to document what you support, test the highest-value journeys, catch compatibility issues, and make an explicit launch decision.

1. Agree and document the support matrix

Start with evidence about who will use the site and what the project must support. MDN notes that cross-browser testing across every browser and device is impractical; “important” targets are generally those common among the target audience. Treat familiar browser names as candidates, not a universal checklist. MDN’s introduction to cross-browser testing explains how to choose targets.

Review first-party audience data, intended markets, and project or contractual requirements.
Record browser families and supported versions, operating systems, device classes, and representative viewport sizes.
Include older versions only when audience evidence or requirements justify them.
Consider desktop Chrome, Firefox, Safari, and Edge, plus common iOS and Android browsers where relevant to your audience.
List critical CSS, JavaScript, and browser API dependencies; check their support in the target versions using MDN’s browser compatibility guidance.
Define what “works” means for each target, including acceptable fallback behavior for nonessential enhancements.
Document exclusions and known limitations, and get the site owner’s agreement.

A matrix can start small and grow as evidence or requirements warrant. For example:

Target	Version or platform rule	Device class and viewport	Why it is included	Validation method
Desktop browser family	Agreed supported version range	Laptop or desktop; representative width	Audience data or requirement	Automated project plus manual review
Mobile browser family	Agreed supported version range	Phone; representative narrow viewport	Audience data or requirement	Emulation and, where possible, real device
Tablet browser family	Agreed supported version range	Tablet; portrait and landscape as needed	Audience data or requirement	Emulation and targeted device check

2. Test changes early, then expand coverage

Do not wait until the release candidate to discover basic incompatibilities. MDN recommends checking changes during development, starting with a couple of stable browsers and a mobile platform, then broadening to the agreed matrix. See MDN’s testing approach.

During development, check new layout and interaction changes in a small representative set.
Before launch, run the full agreed matrix against the release build.
After a fix, retest the affected configuration and rerun the relevant regression checks.

3. Exercise the important user journeys

List the tasks that matter to this website. Run each journey from its entry point through completion in every target configuration, or in a documented representative subset where automation provides appropriate coverage.

Navigate to important content or product areas.
Use search, filters, or navigation controls if the site provides them.
Submit key forms and verify validation, success, and error states.
Complete a purchase, booking, or other transaction if applicable.
Check sign-in, account recovery, or other account flows if applicable.
Confirm controls respond, state changes are visible, and errors explain what the user can do next.

For each journey, record whether the task completed and any configuration-specific difference. Prioritize defects that block a core task or prevent access to essential content.

4. Inspect layout and responsive behavior

Review key pages at representative phone, tablet, and desktop sizes from the support matrix.
Check navigation, content, forms, dialogs, images, and controls for clipping, overlap, unreadable text, or awkward scrolling.
Check orientation changes and viewport resizing where users are likely to encounter them.
Compare against visual requirements and design intent; allow reasonable platform differences rather than demanding pixel-identical output.
Use device emulation to broaden viewport coverage, then confirm important behavior on real target hardware when available.

Emulation is useful for efficient layout checks, but it does not establish every behavior of a physical device. MDN recommends physical device testing where possible and identifies emulators and virtual machines as alternatives. MDN’s guidance covers both approaches.

5. Check feature support and graceful fallbacks

Review browser compatibility for newer CSS, JavaScript, and browser APIs that are central to the experience. For every dependency that is missing in a supported target, verify a fallback or graceful degradation path.

Confirm core content and actions still work when a nonessential visual effect or enhancement is unavailable.
Test media playback and other platform-dependent capabilities in the actual target browser and operating system when they matter. Codec and feature availability can vary by browser build and platform; see Playwright’s project documentation.
Check that unsupported features fail in a controlled, understandable way instead of breaking the whole page.

6. Include accessibility in the compatibility pass

Browser coverage is incomplete if people cannot use the essential experience. Establish the accessibility target required by the project and applicable obligations. MDN mentions WCAG AA as an example target; it is not a substitute for determining the standard that applies to your project. MDN’s introduction discusses accessibility in testing.

Complete essential journeys with a keyboard only. Check focus order, visible focus, and operation of menus, dialogs, and forms.
Use a screen reader on representative platforms. Check names, roles, labels, reading order, and whether status and error messages are announced clearly.
Verify that core content and functions remain available when advanced effects or nonessential features are disabled or unsupported.
Record the target standard, tested configurations, issues, and any accepted exceptions.

7. Combine automated and hands-on checks

Automation makes repeated regression checks practical, while hands-on checks cover device behavior and interaction details that a test suite may not establish.

Run Playwright across browser projects

Playwright projects let a test suite run with Chromium, Firefox, and WebKit, as well as branded Chrome and Edge channels and emulated device configurations. Add projects that match the support matrix; a Playwright engine project does not by itself guarantee testing every branded browser build or physical device. Consult the Playwright Projects documentation for supported configuration options and current device profiles.

// playwright.config.js
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile-chromium', use: { ...devices['Pixel 7'] } },
    { name: 'mobile-webkit', use: { ...devices['iPhone 13'] } },
    // Add branded channels when required by the target matrix:
    // { name: 'chrome', use: { ...devices['Desktop Chrome'], channel: 'chrome' } },
    // { name: 'msedge', use: { ...devices['Desktop Edge'], channel: 'msedge' } },
  ],
});

Example journey test (adjust selectors and expected behavior to your site):

// tests/critical-journey.spec.js
import { test, expect } from '@playwright/test';

test('visitor can submit the contact form', async ({ page }) => {
  await page.goto('https://example.com/contact');
  await page.getByLabel('Email').fill('person@example.com');
  await page.getByLabel('Message').fill('Please contact me.');
  await page.getByRole('button', { name: 'Send' }).click();
  await expect(page.getByRole('status')).toContainText('Thank you');
});

Install Playwright and its browser builds using the project’s documented setup instructions, then run the configured projects with npx playwright test. Keep Playwright and its browser builds current so the suite covers recent browser versions and catches changes early, as recommended in the Playwright documentation. Select actual stable target browsers and real devices for final confirmation where the matrix requires them.

Use screenshots to review visual state

Capture the same important page states at agreed viewports and compare them against requirements or reviewed baselines. A screenshot is evidence of appearance at one moment and configuration; it does not prove that a form submits, keyboard interaction works, or content is accessible.

8. Record results and make the launch decision

For each issue, record:

Browser and version, operating system, device or viewport, and test date/build.
Reproduction steps, expected result, and actual result.
Severity and whether a core journey or essential access is blocked.
Evidence, such as a screenshot or concise recording, when useful.
Fix status, retest result, and any accepted limitation with its owner.

Before launch, retain the support matrix, results, known limitations, and named acceptance of remaining exceptions. The launch decision should state which targets were checked and which known issues are accepted.

9. Or skip the browser setup

For page appearance checks, ScreenshotNeo can return a screenshot with one GET request. It is a website screenshot API and MCP server from ScreenshotNeo. The call below captures the example URL; see the ScreenshotNeo API documentation for request options.

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,
)
r.raise_for_status()
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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(({ writeFile }) => writeFile('shot.webp', res));

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses include X-Page-Verdict and X-Billed headers.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000; every feature is on every plan.

10. Troubleshooting common cross-browser issues

Symptom	Likely cause	What to check or do
A layout overflows or overlaps on one target	Different viewport, font metrics, unsupported CSS, or an assumption about available width	Reproduce at the recorded viewport; inspect the relevant compatibility data; add responsive rules or a fallback and retest.
A control looks correct but does not complete its task	Functional behavior differs from the visual state, or a script/API dependency is unavailable	Run the journey and inspect console/network errors; verify feature support and provide a fallback for supported targets.
A media file plays on one platform but not another	Codec or media capability differs by browser build or operating system	Test the real target combination and provide supported formats or a clear fallback where required.
Automated test passes in one project and fails in another	Timing assumptions, selectors, browser differences, or environment setup	Use stable user-facing selectors and condition-based waits; inspect traces and reproduce against the specific project before changing expected behavior.
Emulation passes but users still report a device issue	Emulation does not reproduce every physical-device behavior	Retest on representative physical hardware and operating system versions where the issue matters.
A newer API works in current browsers but fails on an older supported version	The feature is absent or behaves differently in that version	Check compatibility data, add a fallback or revise the support commitment with owner agreement.
Keyboard or screen-reader users cannot complete a core task	Focus, labels, semantics, announcements, or interaction support is incomplete	Reproduce with the relevant assistive technology, fix the accessibility issue, and rerun the journey.

11. Performance, reliability, and cost

Keep the matrix proportional. A documented representative matrix is more maintainable than an unbounded list. Use audience evidence and risk to decide where additional versions or devices justify the cost.
Run broad suites deliberately. More browser projects and device configurations increase execution and maintenance work. Run a small set on frequent changes and the complete agreed set at release checkpoints if that fits the project.
Keep results reproducible. Record browser builds, operating systems, viewports, test data, and release build so a reported difference can be reproduced.
Separate visual evidence from functional evidence. Screenshots help review appearance, while journey tests and manual checks establish interaction, accessibility, and device behavior.
Budget real hardware by risk. Prioritize physical device checks for audience-critical platforms, media, and issues that emulation cannot settle.

Frequently asked questions

Do I need every browser for every release?

No. Define the supported set from audience evidence and requirements, then test that documented set at an appropriate depth. There is no practical way to cover every possible browser and device combination.

Does a passing screenshot comparison prove the site is ready?

No. It checks appearance in a captured state. You still need to exercise important interactions, keyboard operation, and relevant screen-reader journeys.

Should I test Chrome, Firefox, Safari, and Edge?

They are common desktop candidates in MDN’s examples, but the right list depends on the site’s audience, geography, and requirements. Add mobile targets where your audience or project requires them.

Can automated browser tests replace manual testing?

They can repeat defined journeys consistently across projects, but representative hands-on checks remain useful for accessibility, physical-device behavior, and issues not encoded in tests.