Cross-Browser and Device Testing Checklist: What to Cover in 2026

In 2026, test every web release on Chrome, Safari on both iPhone and Mac, Edge, Firefox and Samsung Internet, at phone and desktop widths. Those cover about 96% of worldwide browser use on StatCounter data, and mobile is now 59% of traffic. Check layout, forms, logins, payments, media and keyboard access in each. Automate three engines in CI, and finish on real phones before launch.

If you would rather have it tested for you, see how RAITHub would test this below. The checklist works as-is for a developer or tester running a release.

Which browsers should you test on in 2026?

Start with world share, then adjust to your own analytics. StatCounter's figures for September 2026:

Browser	All platforms	Mobile only	Engine
Chrome	66.36%	67.64%	Blink
Safari	18.27%	24.71%	WebKit
Edge	6.04%	Not in the mobile top six	Blink
Firefox	2.80%	0.69%	Gecko
Samsung Internet	2.31%	3.50%	Blink
Opera	1.77%	1.38%	Blink

Sources: StatCounter browser share and StatCounter mobile browser share. Mobile was 58.99% of worldwide traffic, desktop 39.26% and tablet 1.76% (StatCounter platform share). Your users may look very different: a B2B dashboard can be 90% desktop Chrome and Edge, while a consumer app in some markets is mostly Android.

The engine column matters more than the brand. Chrome, Edge, Samsung Internet and Opera all use Blink, so they share most rendering bugs. Safari's WebKit and Firefox's Gecko are where real differences appear. Google's Baseline project uses the same idea: a feature is "Baseline Newly available" when it works in the core set of Chrome, Edge, Firefox and Safari on desktop and mobile, and "Widely available" 30 months later.

Is Chrome on iPhone the same as Safari?

Mostly, yes. Outside the European Union, browsers on iPhone and iPad use Apple's WebKit engine, so Chrome on iOS renders like Safari. Apple allows alternative browser engines only for users in the EU, on iOS 17.4 or iPadOS 18 and later (Apple: alternative browser engines in the EU). In practice, testing Safari on a real iPhone covers most iOS users; EU-heavy products should add Chrome on iOS as a separate check.

What is a sensible browser and device matrix?

Priority	Browser and device	How to test
Every release	Chrome desktop; Safari on iPhone; Chrome on a mid-range Android phone	Automated in CI plus a manual pass on the core journeys
Every release	Safari on Mac; Edge on Windows; Firefox desktop	Automated in CI on all three engines
Before launch and major releases	Samsung Internet; an iPad; a small phone; a large or foldable phone	Real devices or a device cloud
If your analytics show it	Older iOS versions, in-app browsers (Instagram, Facebook, LinkedIn), regional browsers	Targeted manual checks

In-app browsers are often forgotten. A link shared in a social app opens in that app's embedded browser, where pop-ups, downloads and some sign-in flows behave differently. If you market through social media, test the sign-up journey from inside those apps.

The cross-browser checklist

Layout and responsive design

• Breakpoints at 360, 390, 768, 1024, 1280 and 1440 pixels wide, with no horizontal scroll.
• Full-height sections on mobile: the address bar shows and hides, so check sticky headers, footers and modals as you scroll.
• The iPhone notch and home indicator do not cover buttons (safe areas).
• Long words, translated strings and right-to-left text do not break layouts. Our Arabic and RTL QA checklist covers RTL in depth.
• Dark mode, if supported, in each engine.

Forms and input

• Date, time and number inputs: each engine draws its own picker.
• Autofill and password managers fill the right fields.
• The on-screen keyboard does not cover the focused field or the submit button.
• Validation messages appear and are announced, in every browser.
• File uploads from the phone camera and photo library.

Login, sessions and payments

• Sign-in, single sign-on and "sign in with" buttons in Safari, where privacy features treat third-party cookies and cross-site storage more strictly.
• Sessions survive a tab sleeping in the background on mobile.
• Payment redirects and 3-D Secure pop-ups or iframes complete and return to the right page.
• Email links, magic links and password reset links open correctly on mobile.

Media, files and printing

• Videos play inline on iPhone and respect autoplay rules (muted autoplay only).
• Downloads of PDFs and CSVs work on iOS and Android.
• Invoices and reports print cleanly, if users print.

Accessibility across browsers

• Keyboard only: every control reachable, visible focus, no traps, in Safari and Firefox as well as Chrome.
• Zoom to 200% and larger text without lost content.
• Screen reader spot checks: VoiceOver with Safari, and NVDA with Chrome or Firefox.

For full WCAG 2.2 coverage, use our accessibility testing checklist. An accessibility audit lists issues and fixes; it does not certify legal compliance.

Performance on real hardware

• Load and interact on a mid-range Android phone over a throttled connection, not only on a fast laptop.
• Heavy pages (maps, charts, long tables) stay responsive in Safari and Firefox.

How do you automate cross-browser tests?

Playwright runs the same tests in Chromium, Firefox and WebKit, and can emulate phone viewports. This config runs every test in five projects:

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

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  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 7'] } },
    { name: 'mobile-safari', use: { ...devices['iPhone 13'] } },
  ],
})

Know what this does and does not cover. Playwright's device emulation sets the user agent, screen size, viewport and touch support (Playwright emulation), and its projects can also target branded Chrome and Edge channels (Playwright projects). It does not run a real iPhone or Samsung phone. WebKit in Playwright is close to Safari, but on-screen keyboards, real touch, address-bar behaviour and phone performance still need real devices. Our comparison of Playwright vs Cypress explains the engine support in each tool, and real devices, emulators or a device cloud covers when hardware matters.

How long does a cross-browser pass take yourself?

As a rough guide: a manual pass over ten key pages and the core journeys on six browser and device combinations takes one tester about one to two days. Once the Playwright projects above are in place, the automated part runs in minutes on each pull request, and the manual pass shrinks to the real-device and accessibility checks. The main risk of doing it yourself is testing on the browser you develop in and calling it done: most cross-browser bugs live in Safari on iPhone, which many developers do not use daily.

Buy, build or hire?

Option	Choose this when	Trade-off
A tool or SaaS testing platform (Playwright in CI, a browser and device cloud)	Your developers will maintain the tests and run the manual checks	Low tool cost; real-device checks often get skipped under deadline
Freelancers or crowdtesting	You want many real browsers and devices checked before a launch	Broad reach; report depth and consistency vary
An in-house QA hire	You release weekly and the web app is your core product	Strong context; one person's device shelf and months to hire
A managed QAaaS team	You want the matrix, the automation and the manual passes owned for you	Vendor dependency; make sure tests and reports stay yours

Why RAITHub for this

• Automation plus real devices. RAITHub sets up Playwright projects across all three engines in your CI and runs manual passes on real phones and tablets.
• Proven web test suites. RAITHub's web products run large automated suites: 1,024 tests on PropDesk, 530+ on Sundor Skin, 750+ on TheSkinProof (the founder's own venture, not a client), and 400+ on this site.
• Accessibility in the same pass. Keyboard, zoom and screen reader checks are part of the matrix, with full WCAG 2.2 AA audits available.
• Managed, not placed. A monthly QA plan, a fixed-price audit, or a dedicated team that RAITHub manages and bills monthly. It is not staff augmentation.

When you don't need us

• Your users are almost all on one desktop browser, such as an internal tool on a managed Windows fleet.
• You already run Playwright on three engines and only need occasional real-device checks; a device cloud subscription is enough.
• Your site is a simple marketing page built on a well-tested template.

How RAITHub would test this

• Matrix: build the browser and device list from your analytics, with the every-release and pre-launch tiers above.
• Automation: Playwright projects for Chromium, Firefox, WebKit and mobile viewports, gated in your CI on the core journeys.
• Manual pass: real iPhone, Android and tablet checks for forms, logins, payments, media and in-app browsers.
• Accessibility checks: keyboard, zoom and screen reader spot checks in each engine.
• What you receive: the matrix, bug reports with browser, device, version and steps, tests in your repository, and a handover note. IP is yours; an NDA is standard.

Scope, timeline and cost come in a written fixed quote after a free 15-minute technical audit. See manual testing, QA and test automation, accessibility testing and the QA as a service overview. For native apps, use the mobile app testing checklist instead. To start, ask for a pre-launch cross-browser audit.

Frequently asked questions

Which browsers should I test my website on in 2026?

Chrome, Safari on iPhone and Mac, Edge, Firefox and Samsung Internet cover about 96% of worldwide use on StatCounter's September 2026 data. Adjust the list to your own analytics, and add in-app browsers if your traffic comes from social media.

Do I need to test Chrome on iPhone separately from Safari?

Usually not. Outside the EU, iOS browsers use Apple's WebKit engine, so they render like Safari. In the EU, Apple allows other engines from iOS 17.4, so EU-heavy products should add a separate check.

Is Playwright's WebKit the same as Safari?

It is close, because it is built from WebKit, but it is not Safari on a real iPhone. On-screen keyboards, touch, address-bar behaviour and phone performance still need a real device check.

How many devices do I need for cross-browser testing?

For most web apps: one iPhone, one mid-range Android phone, one Mac and one Windows machine, plus a device cloud for occasional checks on tablets, small phones and older versions.

Can cross-browser testing be fully automated?

Most of the regression work can, with Playwright across three engines in CI. Visual polish, real touch and keyboard behaviour, and screen reader checks still need a person on a real device.

Does an accessibility check in this pass make my site legally compliant?

No. It finds and reports issues against WCAG 2.2 AA with fixes, but it is not a legal certification under the ADA, the European Accessibility Act or Section 508. This is general information; confirm legal obligations with your adviser.