Cross-Browser Testing: What It Is, Tools, and How to Do It

Parul Dhingra13+ Years Experience

Senior Quality Analyst at Deloitte

Updated: 1/22/2026

Cross-browser testing verifies that your web application looks and functions correctly across different browsers, operating systems, and devices. When a user opens your site in Chrome, Safari, Firefox, or Edge, they should have the same experience.

The challenge is that browsers use different rendering engines. Chrome and Edge use Blink. Firefox uses Gecko. Safari uses WebKit. Each engine interprets your CSS, JavaScript, and HTML slightly differently.

This guide covers which browsers to test, the tools that make testing practical, common issues you will encounter, and automation strategies that scale.

What is Cross-Browser Testing

Cross-browser testing is the practice of verifying that a web application works correctly across different web browsers. This includes checking visual appearance, functional behavior, and performance.

A button that works in Chrome might not respond in Safari. A dropdown menu that displays properly in Firefox might overlap content in Edge. A CSS grid layout that looks perfect on desktop Chrome might break entirely in older mobile browsers.

The goal is consistency. Users should get the same experience regardless of which browser they choose. When cross-browser testing fails, users see broken layouts, non-functional buttons, or error messages.

Cross-browser testing differs from general functional testing because it focuses specifically on browser-related differences rather than application logic. Your login form might work correctly - the issue is that the submit button is invisible on Safari.

Types of Cross-Browser Testing

Functional testing verifies that features work across browsers. Does the checkout process complete? Does form validation fire correctly? Can users navigate between pages?

Visual testing compares how pages render. Are fonts displaying correctly? Is the layout consistent? Are images loading at the right size?

Performance testing measures speed and responsiveness. How fast does the page load in Firefox versus Chrome? Are there JavaScript execution differences?

Responsive testing checks how layouts adapt across viewport sizes and device types within each browser.

Why Browsers Render Things Differently

Understanding why browsers behave differently helps you write better code and anticipate problems.

Different Rendering Engines

The rendering engine is the core component that converts HTML, CSS, and JavaScript into the visual page you see.

Modern browser rendering engines and their relationships

Because Chrome, Edge, and Opera all use Blink, they typically render pages identically. The real differences appear between Blink, Gecko, and WebKit.

CSS Implementation Differences

CSS specifications are interpreted differently by each engine. Flexbox and Grid are standardized, but edge cases vary:

• Gap property in Flexbox: Older Safari versions did not support gap in flexbox layouts
• Subgrid: Firefox implemented subgrid years before other browsers
• Container queries: Support timing varied significantly across browsers
• CSS transforms: Performance and anti-aliasing differ between engines

JavaScript Engine Differences

Each browser has its own JavaScript engine:

• Chrome: V8
• Firefox: SpiderMonkey
• Safari: JavaScriptCore (Nitro)

Modern ECMAScript features are usually consistent, but timing and edge cases differ. A Promise chain might behave slightly differently. Date parsing can produce different results. Regular expression engines have subtle variations.

Font Rendering

Font rendering is visually obvious and hard to control. macOS uses subpixel antialiasing that makes text appear heavier. Windows ClearType produces different results. Linux distributions vary widely. The same font at the same size looks different across operating systems and browsers.

Which Browsers to Test

Testing every browser version on every operating system is impractical. You need a strategy based on your actual users.

Start With Your Analytics

Check your analytics to see what browsers your users actually use. This data determines your priorities.

If your analytics show:

• 65% Chrome
• 20% Safari
• 8% Edge
• 4% Firefox
• 3% Other

Then Chrome and Safari are essential. Edge is important. Firefox is worth testing but not critical. Everything else is low priority.

Do not rely on global statistics. Your audience may differ significantly. A developer tools site will have more Firefox users. A B2B enterprise app will have more Edge users. An iOS-focused app will have more Safari users.

Priority Tiers

Tier 1 (Must Test)

• Chrome (latest and one version back) on Windows and macOS
• Safari (latest) on macOS and iOS
• Mobile Chrome and Safari (latest versions)

Tier 2 (Should Test)

• Firefox (latest) on Windows and macOS
• Edge (latest) on Windows
• Samsung Internet on Android (if your analytics show significant usage)

Tier 3 (Test When Possible)

• Older browser versions based on your support policy
• Regional browsers if you serve specific markets

Version Coverage

Browser auto-updates mean most users run recent versions. A practical approach:

• Current version: Required
• Previous major version: Recommended
• Two versions back: Optional unless you have specific support requirements

For Safari, version coverage matters more because iOS updates lag behind macOS updates, and users do not always upgrade their operating systems.

Cloud Testing Platforms

Cloud testing platforms provide access to hundreds of browser and operating system combinations without maintaining physical devices or virtual machines.

BrowserStack

BrowserStack offers real devices and browsers in the cloud. You can run manual tests through their web interface or automated tests via their API.

Key features:

• Real device testing (not emulators for mobile)
• Parallel test execution
• Local testing tunnel for staging environments
• Screenshot and video recording
• Integration with major test frameworks

Pricing: Starts around $29/month for manual testing. Automation plans are usage-based.

Best for: Teams that need real device testing and broad browser coverage.

Sauce Labs

Sauce Labs focuses on automated testing at scale. It integrates with CI/CD pipelines and provides detailed analytics on test results.

Key features:

• Large browser and device library
• Parallel execution up to 1000+ concurrent sessions
• Visual testing capabilities
• Performance analytics
• Strong enterprise security features

Pricing: Enterprise-focused pricing, typically starts at higher tiers than BrowserStack.

Best for: Enterprise teams with large test suites and high parallelization needs.

LambdaTest

LambdaTest provides similar capabilities at competitive pricing. It includes both real devices and simulators.

Key features:

• 3000+ browser and device combinations
• Real-time browser testing
• Automated screenshot testing
• Geolocation testing
• HyperExecute for faster parallel testing

Pricing: Free tier available. Paid plans start around $15/month.

Best for: Teams wanting broad coverage at lower cost.

Platform Comparison

Comparison of major cloud testing platforms

Automation Frameworks

Automated cross-browser testing saves time and catches regressions. The major frameworks each have strengths.

Playwright

Playwright is Microsoft's automation framework. It supports Chrome, Firefox, and Safari out of the box with a single API.

Advantages:

• Single API for all browsers
• Auto-wait functionality reduces flaky tests
• Built-in test runner
• Excellent debugging with trace viewer
• Network interception and mocking
• Mobile viewport and device emulation

Code example:

import { test, expect } from '@playwright/test';
 
test('checkout works across browsers', async ({ page }) => {
  await page.goto('https://example.com/products');
  await page.click('[data-testid="add-to-cart"]');
  await page.click('[data-testid="checkout"]');
  await expect(page.locator('.order-confirmation')).toBeVisible();
});

Run across browsers:

npx playwright test --project=chromium --project=firefox --project=webkit

Playwright is the best choice for new projects. It handles modern web applications well and reduces test maintenance.

Selenium WebDriver

Selenium has been the standard for browser automation since 2004. It supports more browsers and has the largest ecosystem.

Advantages:

• Supports all major browsers and many minor ones
• Language bindings for Java, Python, JavaScript, C#, Ruby
• Selenium Grid for parallel execution
• Huge community and documentation
• Works with cloud platforms

Disadvantages:

• More boilerplate code
• Flakier without explicit waits
• Slower than newer frameworks

Selenium remains relevant for teams with existing test suites, enterprise requirements, or need for specific browser support not available in newer frameworks.

Cypress

Cypress runs tests directly in the browser rather than controlling it externally. This provides fast execution and excellent debugging.

Advantages:

• Fast execution
• Automatic waiting
• Time-travel debugging
• Real-time reloading
• Excellent documentation

Limitations:

• Chrome, Edge, Firefox, and Electron only (no Safari)
• Cannot visit multiple domains in one test
• Limited iframe support

Cypress is excellent for Chrome-focused testing but the lack of Safari support is significant for many teams.

Framework Selection Guide

Framework recommendations based on project requirements

Common Cross-Browser Issues

These are the problems you will encounter most frequently and how to address them.

CSS Layout Issues

Flexbox gaps: The gap property for flexbox was not supported in Safari until version 14.1 (2021). Older Safari users see no gaps between flex items.

/* Works in modern browsers */
.container {
  display: flex;
  gap: 16px;
}
 
/* Fallback for older Safari */
.container > * + * {
  margin-left: 16px;
}

Grid layout differences: CSS Grid is well-supported, but subgrid support varies. Firefox added subgrid in 2019. Safari added it in 2022. Chrome added it in 2023.

Position sticky: Works differently in Safari, especially inside elements with overflow: hidden or in certain scrolling contexts.

JavaScript Compatibility

ES6+ features: Modern JavaScript is supported everywhere, but edge cases exist. Optional chaining (?.) and nullish coalescing (??) need transpilation for older browsers.

Date parsing: The Date constructor interprets strings differently across browsers. Always use ISO 8601 format (YYYY-MM-DDTHH:mm:ss.sssZ) for consistent results.

// Inconsistent across browsers
new Date('2024-01-15') // May be UTC or local time
 
// Consistent across browsers
new Date('2024-01-15T00:00:00.000Z')

Clipboard API: Permissions and behavior differ. Safari requires user gesture for clipboard access. Some browsers restrict clipboard access to secure contexts only.

Form Input Behavior

Date inputs: Native date pickers vary significantly. Chrome and Edge show a calendar. Firefox shows a text input with validation. Safari shows a calendar but with different formatting.

Autofill: Browser autofill behavior is inconsistent. Field names, autocomplete attributes, and detection methods vary.

Validation messages: Native HTML5 validation messages are styled differently and cannot be customized consistently.

Font and Typography Issues

Font loading: FOUT (Flash of Unstyled Text) and FOIT (Flash of Invisible Text) behave differently. Safari holds invisible longer than Chrome.

Font weight rendering: The same font weight appears heavier on macOS than Windows. This is operating system level, not browser level, but testing must account for it.

Line height calculation: Different engines calculate line height slightly differently, causing text wrapping at different points.

Testing tip: Always test typography-heavy pages across macOS and Windows. What looks good in Chrome on Mac may have clipped descenders or different line breaks on Windows.

Scroll Behavior

Smooth scrolling: scroll-behavior: smooth works differently or not at all across browsers.

Scroll position restoration: Browser handling of scroll position on navigation varies.

Momentum scrolling: iOS momentum scrolling causes issues with scroll-linked animations and sticky positioning.

Setting Up Automated Cross-Browser Tests

A practical setup for automated cross-browser testing using Playwright with a cloud platform.

Project Structure

tests/
  e2e/
    checkout.spec.ts
    login.spec.ts
    navigation.spec.ts
  visual/
    homepage.spec.ts
    product-page.spec.ts
playwright.config.ts

Configuration

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';
 
export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: 'html',
 
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
    {
      name: 'Mobile Chrome',
      use: { ...devices['Pixel 5'] },
    },
    {
      name: 'Mobile Safari',
      use: { ...devices['iPhone 12'] },
    },
  ],
 
  webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

Writing Cross-Browser Tests

Tests should not contain browser-specific logic. If you find yourself writing if (browser === 'safari') blocks, there is usually a better approach.

import { test, expect } from '@playwright/test';
 
test.describe('Product checkout', () => {
  test('can add product to cart and complete purchase', async ({ page }) => {
    await page.goto('/products/widget');
 
    // Add to cart
    await page.getByRole('button', { name: 'Add to Cart' }).click();
    await expect(page.getByTestId('cart-count')).toHaveText('1');
 
    // Go to checkout
    await page.getByRole('link', { name: 'Checkout' }).click();
 
    // Fill shipping info
    await page.getByLabel('Email').fill('test@example.com');
    await page.getByLabel('Address').fill('123 Test St');
    await page.getByLabel('City').fill('Test City');
 
    // Complete order
    await page.getByRole('button', { name: 'Place Order' }).click();
 
    // Verify confirmation
    await expect(page.getByText('Order Confirmed')).toBeVisible();
  });
});

Running Tests

# Run all browsers locally
npx playwright test
 
# Run specific browser
npx playwright test --project=webkit
 
# Run with visible browser
npx playwright test --headed
 
# Debug mode with inspector
npx playwright test --debug

CI/CD Integration

Cross-browser tests should run on every pull request. This catches regressions before they reach production.

GitHub Actions Example

name: Cross-Browser Tests
 
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
 
      - name: Install dependencies
        run: npm ci
 
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
 
      - name: Run Playwright tests
        run: npx playwright test
 
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Test Strategy for CI

Not every test needs to run on every browser for every commit. A tiered approach balances coverage with speed:

On every pull request:

• Full test suite on Chrome (fastest feedback)
• Critical path tests on Firefox and Safari

On merge to main:

• Full test suite on all browsers

Nightly:

• Full suite including older browser versions
• Visual regression tests
• Performance benchmarks

# Conditional browser selection
- name: Run tests
  run: |
    if [ "${{ github.event_name }}" == "pull_request" ]; then
      npx playwright test --project=chromium
      npx playwright test --grep @critical --project=firefox --project=webkit
    else
      npx playwright test
    fi

Mobile Browser Testing

Mobile browsers require specific attention because they have different capabilities and constraints.

iOS Safari Specifics

All browsers on iOS use WebKit. Chrome on iOS is not Chrome's Blink engine - it is Safari with a Chrome UI. This means:

• WebKit bugs affect all iOS browsers
• Chrome-specific features do not exist on iOS Chrome
• Safari extensions and capabilities define what is possible

Common iOS Safari issues:

• 100vh does not account for the URL bar
• Position fixed elements behave differently
• Smooth scrolling and momentum affect touch interactions
• Service Worker support has limitations

Android Browser Landscape

Android has more browser diversity:

• Chrome (Blink) - most common
• Samsung Internet (Blink-based) - significant share on Samsung devices
• Firefox (Gecko)
• Various OEM browsers

Samsung Internet is worth testing separately despite being Chromium-based. It has unique features and its own rendering quirks.

Mobile-Specific Test Considerations

// playwright.config.ts - mobile projects
projects: [
  {
    name: 'Mobile Chrome',
    use: {
      ...devices['Pixel 5'],
      // Touch events
      hasTouch: true,
      // Viewport
      viewport: { width: 393, height: 851 },
    },
  },
  {
    name: 'Mobile Safari',
    use: {
      ...devices['iPhone 12'],
      hasTouch: true,
      viewport: { width: 390, height: 844 },
    },
  },
]

Test for mobile-specific behaviors:

• Touch gestures (swipe, pinch, long press)
• Viewport changes when keyboard appears
• Orientation changes
• Different click behavior (300ms delay, touch-action)

Visual Regression Testing

Visual regression testing catches CSS and layout changes that functional tests miss.

How It Works

1. Capture baseline screenshots of pages/components
2. After code changes, capture new screenshots
3. Compare pixel-by-pixel or use perceptual algorithms
4. Flag differences for review

Playwright Visual Testing

import { test, expect } from '@playwright/test';
 
test('homepage visual regression', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveScreenshot('homepage.png');
});
 
test('product card component', async ({ page }) => {
  await page.goto('/components/product-card');
  const card = page.getByTestId('product-card');
  await expect(card).toHaveScreenshot('product-card.png');
});

Managing Visual Test Baselines

Each browser and operating system produces different screenshots. You need separate baselines for each.

tests/
  homepage.spec.ts-snapshots/
    homepage-chromium-linux.png
    homepage-firefox-linux.png
    homepage-webkit-linux.png
    homepage-Mobile-Chrome-linux.png
    homepage-Mobile-Safari-linux.png

Visual testing challenge: Tests run on Linux in CI but developers use Mac or Windows. Screenshots will always differ. Solution: commit CI-generated baselines and update them through CI.

Handling Dynamic Content

Dynamic content breaks visual tests. Approaches to handle it:

// Mask dynamic elements
await expect(page).toHaveScreenshot('page.png', {
  mask: [page.locator('.timestamp'), page.locator('.user-avatar')],
});
 
// Wait for animations to complete
await page.evaluate(() => document.fonts.ready);
await page.waitForLoadState('networkidle');
 
// Disable animations
await page.addStyleTag({
  content: `
    *, *::before, *::after {
      animation-duration: 0s !important;
      transition-duration: 0s !important;
    }
  `
});

Performance Differences Across Browsers

Browsers execute JavaScript and render pages at different speeds. This affects user experience and should be measured.

What to Measure

Core Web Vitals:

• Largest Contentful Paint (LCP)
• First Input Delay (FID) / Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)

Additional metrics:

• Time to First Byte (TTFB)
• First Contentful Paint (FCP)
• Total Blocking Time (TBT)

Browser Performance Patterns

General observations (these vary by application):

• V8 (Chrome) typically executes JavaScript faster
• WebKit (Safari) has efficient memory usage
• Gecko (Firefox) handles complex CSS animations well
• Mobile browsers are constrained by device hardware, not browser engine

Measuring with Playwright

test('measure page load performance', async ({ page }) => {
  await page.goto('/');
 
  const metrics = await page.evaluate(() => {
    const navigation = performance.getEntriesByType('navigation')[0];
    const paint = performance.getEntriesByType('paint');
 
    return {
      domContentLoaded: navigation.domContentLoadedEventEnd,
      loadComplete: navigation.loadEventEnd,
      firstPaint: paint.find(p => p.name === 'first-paint')?.startTime,
      firstContentfulPaint: paint.find(p => p.name === 'first-contentful-paint')?.startTime,
    };
  });
 
  console.log(`Browser: ${browserName}`);
  console.log(`FCP: ${metrics.firstContentfulPaint}ms`);
  console.log(`Load: ${metrics.loadComplete}ms`);
});

Building Your Browser Testing Matrix

A testing matrix documents which browsers you test, how you test them, and when.

Sample Matrix

Example browser testing matrix for a web application

Updating Your Matrix

Review your matrix quarterly:

1. Check analytics for browser usage changes
2. Remove browsers that dropped below your threshold
3. Add browsers that grew significant
4. Update version requirements based on your support policy
5. Adjust automation coverage based on defect patterns

Documentation

Document your browser support policy:

## Browser Support Policy
 
### Fully Supported
These browsers are tested on every release. Bugs are treated as high priority.
- Chrome (latest 2 versions)
- Safari (latest 2 versions)
- Firefox (latest version)
- Edge (latest version)
 
### Partially Supported
These browsers are tested periodically. Major bugs are fixed; minor issues may be deferred.
- Chrome (versions 3-4 back)
- Safari on older iOS versions
 
### Not Supported
These browsers are not tested. Issues will not be fixed.
- Internet Explorer
- Browsers older than 2 years

Cross-browser testing ensures your users get consistent experiences regardless of their browser choice. Start with your analytics to identify priorities, use automation frameworks and cloud platforms to scale testing, and integrate tests into your CI/CD pipeline for continuous validation. The investment in cross-browser testing pays off through reduced support tickets, better user satisfaction, and fewer production incidents.

Continue Reading

Frequently Asked Questions (FAQs) / People Also Ask (PAA)