What Browsers Should You Test Your Website On?

Liviu Lupei

Founder & Solutions Architect, Endtest · May 18, 2026

Start with the browsers your users actually use

The best answer to "what browsers should you test your website on?" is not "all of them."

That sounds thorough, but it usually turns browser testing into a slow, expensive, inconsistent process that teams eventually stop doing.

The better answer is to test the browsers, devices, and operating systems that matter most to your users, your revenue, and your product risk.

For many websites and web applications, a practical starting point looks like this:

That last row is the most important one.

Generic browser market share is useful, but your own website data is more useful. A B2B SaaS product, a local ecommerce store, a media website, a bank, and a travel booking platform may all have very different browser usage patterns.

Instead of asking "What browsers are popular globally?", ask "What browsers do our visitors, leads, customers, and paying users actually use?"

Ask your Marketing Team for Analytics data

Before deciding what browsers to test, talk to your Marketing Team.

They are usually the people who already have access to Google Analytics, Adobe Analytics, Plausible, Matomo, or another analytics platform. Ask them for a breakdown of:

• Browser
• Browser version
• Device category
• Operating system
• Screen resolution
• Country or region
• Conversion rate by browser and device
• Revenue or lead volume by browser and device
• Drop-off rate on key pages by browser and device

This is where browser testing becomes more than a QA task.

For example, Safari desktop may be only 8% of total visits, but 18% of revenue. Edge may not be very popular on your marketing pages, but it may be heavily used inside enterprise accounts after login. Chrome on Android may have a lower conversion rate than Chrome on desktop, not because Android users are less interested, but because the checkout button is covered by a sticky banner on certain screen sizes.

Analytics data helps you avoid two bad extremes.

The first bad extreme is testing too little:

"It works on my Chrome, so ship it."

The second bad extreme is testing everything manually:

"Let's check 47 browser and device combinations before every release."

The better approach is to build a risk-based browser matrix. Start with the browsers that produce traffic, leads, revenue, and support tickets. Then expand the matrix for areas where the cost of failure is high.

A homepage layout issue might be annoying. A broken checkout flow in Safari is a business problem. A login issue in Edge for enterprise customers is a retention problem. A broken password reset page on mobile is a support problem.

Not all browser bugs are equal.

Use FullStory to find browser-specific journey problems

Analytics can tell you where users drop off. Tools like FullStory can help you understand what happened before they dropped off.

That matters because many browser issues are not obvious from dashboards alone.

A funnel report may show that mobile Safari users abandon the checkout page more often than Chrome users. But the report may not tell you why. A session replay tool can show the actual journey: the user taps a button several times, nothing happens, they scroll up and down, they rage-click, and then they leave.

That kind of evidence is incredibly useful for browser testing.

If you see repeated friction in one browser, add that browser and journey to your test matrix.

For example:

This is how browser testing becomes practical.

You do not need to guess forever. You can use analytics and session replay data to identify where users are actually struggling.

Do not rely only on global browser market share

Global browser market share can be useful for orientation, but it should not be treated as your browser testing strategy.

The global market does not know your audience.

A government portal, a Shopify store, a developer tool, a fintech dashboard, and a local Romanian services website can all have different traffic patterns.

Even inside the same website, different sections can attract different browser mixes.

Your public website may get many mobile visitors. Your logged-in web app may be mostly desktop. Your blog may get Chrome traffic from developers. Your checkout flow may get a lot of Mobile Safari traffic. Your enterprise admin area may be used mostly in Edge on managed Windows machines.

That is why browser testing should be connected to actual user behavior.

A practical browser testing strategy should combine:

• Analytics data
• Conversion data
• Revenue impact
• Support tickets
• Session replay findings
• Product risk
• Customer importance
• Technical complexity

If a browser has low traffic and low business impact, you may not need to test it before every release.

If a browser has moderate traffic but high revenue impact, it should probably be in your critical test matrix.

If a browser is used by a small number of enterprise customers paying a lot of money, it may be more important than a browser with higher anonymous traffic.

Browser testing is a risk management exercise, not a popularity contest.

Test real user journeys, not isolated pages

A browser compatibility checklist should not stop at "the page loads."

Users experience your website as journeys, not as isolated pages.

A checkout journey may involve:

1. Landing on a product page
2. Selecting a variant
3. Adding the product to the cart
4. Opening the cart
5. Applying a discount code
6. Entering shipping details
7. Redirecting to a payment provider
8. Returning to the confirmation page
9. Receiving an email confirmation

A bug can appear at any step. It may not show up if you only load the product page and check that the title is visible.

The same applies to SaaS products:

1. Visit the pricing page
2. Start a trial
3. Verify the email address
4. Log in
5. Create a project
6. Invite a teammate
7. Upload a file
8. Run a workflow
9. View the results
10. Change billing settings

A browser test should prove that the user can complete the outcome. A page rendering is not enough.

This is also where manual testing becomes painful. Running one journey manually is easy. Running ten critical journeys across seven browser and platform combinations after every release is not.

That is why teams either skip browser testing or automate it.

A practical browser testing matrix for marketing websites

For a marketing website, the browser matrix should focus on traffic, conversions, forms, landing pages, and important content templates.

A good starting point is:

Focus on:

• Homepage
• Pricing page
• Signup page
• Contact form
• Demo request form
• Blog templates
• Landing pages
• Navigation menus
• Cookie banners
• Tracking scripts
• Core Web Vitals-sensitive pages

For marketing websites, you should also compare analytics by browser. If one browser has a suspiciously low conversion rate, investigate it.

A low conversion rate in one browser may be caused by audience differences, but it may also point to a bug.

For example:

• A form button may be hidden on mobile Safari.
• A tracking script may break a page in Firefox.
• A consent banner may cover the CTA on Android.
• A video background may cause layout issues in Safari.
• A sticky header may block a key form field on smaller screens.

The goal is to protect the pages that create business value, not to test every page in every browser.

A practical browser testing matrix for SaaS products

For SaaS products, browser testing usually needs to be more serious because users are completing workflows rather than reading content.

A good starting point is:

Focus on:

• Signup
• Login
• SSO
• Password reset
• Main dashboard
• Billing
• Settings
• File uploads
• Reports
• Critical workflows
• Admin flows
• Invitations
• Notifications
• Integrations

For SaaS products, the browser matrix should be connected to customer value.

If enterprise customers use Edge on managed Windows machines, Edge deserves serious coverage. If founders, designers, product managers, or technical users are often on MacBooks, Safari and Chrome on macOS deserve serious coverage. If your application is used in the field, mobile browsers may be critical.

This is where your support team can also help.

Ask them:

• Which browsers appear in bug reports?
• Which customers report the most browser-specific problems?
• Which workflows create the most support tickets?
• Which flows are painful to debug manually?

Your browser testing matrix should reflect the reality of your product, not a generic checklist copied from the internet.

A practical browser testing matrix for ecommerce websites

For ecommerce websites, browser bugs can directly block revenue.

A good starting point is:

Focus on:

• Product listing pages
• Product detail pages
• Search
• Filters
• Add to cart
• Cart updates
• Checkout
• Payment redirects
• Promo codes
• Address forms
• Account creation
• Order confirmation

Checkout deserves special attention.

Many ecommerce teams look at overall browser traffic, but the more important data is revenue by browser and checkout completion rate by browser.

If Safari users represent a meaningful percentage of revenue, Safari testing should not be optional. If Mobile Safari users abandon checkout at an unusual rate, that deserves investigation. If Chrome on Android users struggle with address entry, that journey should be tested.

A browser bug in checkout is one of the clearest examples of a technical issue becoming a business issue.

Do not test only the browser engine

A common mistake is assuming that testing the rendering engine is the same as testing the browser your users actually use.

A browser is a full application running on a real operating system, with its own fonts, graphics stack, media behavior, permissions, input handling, windowing behavior, extensions, security rules, dialogs, downloads, file uploads, and performance characteristics. The rendering engine is only one part of it.

Chrome on Windows, Chrome on macOS, and Chrome on Linux are all Chrome, but they are not identical environments.

The same is true for Safari and WebKit.

WebKit is the browser engine used by Safari, but running a WebKit build is not the same as running the real Safari browser that your users open on macOS. This distinction matters for serious cross-browser testing.

A good analogy is game testing.

Imagine that you want to release a game on PlayStation 5, but you only test the PC version. The game may look similar, the menus may be similar, and the engine may share a lot of code. But the platform, the hardware, the controller behavior, the graphics stack, the certification requirements, and the performance profile are all different.

No serious game studio would say:

"We tested the PC build, so the PlayStation 5 version is definitely fine."

Web testing has a similar problem.

Testing Chrome inside a Linux container is not the same as testing Chrome on a real Windows machine used by your customers. The same goes for a browser engine versus the actual browser, and for WebKit versus real Safari.

For quick development checks, lightweight browser environments are useful. For release confidence, core user journeys should be tested on real browsers running on the operating systems your users actually use.

Why real Windows and macOS browsers matter

Many automated testing setups run in Linux containers because they are cheap, fast, and easy to scale.

That is fine for some types of testing. A Linux-based headless browser can catch many obvious failures:

• Broken selectors
• JavaScript errors
• Missing elements
• Navigation problems
• Basic layout regressions
• Some form submission issues

But it should not be your entire cross-browser strategy.

Real users are on Chrome on Windows laptops, Safari on MacBooks, Edge on corporate desktops, and mobile browsers on real devices, not on headless browsers in Linux containers.

Operating systems affect more than people think.

Fonts, scrollbars, file upload dialogs, download behavior, media codecs, permission prompts, keyboard shortcuts, input behavior, and enterprise browser policies can all differ. Even small differences can break a critical workflow.

This is especially important for:

• Checkout flows
• Login and SSO
• Account creation
• File uploads and downloads
• PDF generation and preview
• Video or audio playback
• Drag and drop
• Complex dashboards
• Browser permissions
• Payment provider redirects
• Multi-window or popup flows
• Email and SMS verification flows

If your website is mostly static content, you can probably get away with a lighter matrix.

If your website is a web application that handles money, accounts, personal data, documents, bookings, subscriptions, or business workflows, real browser coverage becomes much more important.

WebKit is not the same as real Safari

This deserves its own section because it is one of the biggest misunderstandings in modern browser testing.

Playwright is a very useful framework, but its Safari story has a serious limitation: it runs tests on WebKit, not on the real Safari browser used by your customers.

That is not a small detail.

Safari is the browser. WebKit is the engine. They are related, but they are not interchangeable.

This is one area where Selenium historically had an advantage, because Safari includes native WebDriver support through SafariDriver on macOS. That means Selenium-based infrastructure can automate real Safari, rather than a WebKit build intended to approximate Safari-like behavior.

For many teams, this distinction may not matter every day. But when it matters, it really matters.

A Safari-only bug can be expensive. It can happen in checkout, authentication, a calendar widget, file upload, a payment redirect, or a CSS layout that looks fine in Chrome and Firefox.

If your testing strategy says "Safari" but actually means "WebKit," you should be honest about that risk.

A more accurate testing matrix would say:

You do not need to panic about every difference. But you should not pretend the differences do not exist.

Manual browser testing does not scale

Manual testing is useful, especially before big launches. A human tester can notice strange visual issues, awkward interactions, confusing copy, and subtle UX problems.

But manual browser testing has limits.

It is slow and repetitive, it is easy to forget steps, and it is hard to run consistently after every deployment. It becomes even harder when the product grows, the team ships more often, and the number of critical journeys increases.

This is why the long-term solution is automated cross-browser testing.

The goal is to stop wasting human time on repetitive checks that should run automatically, not to replace human judgment.

A mature setup looks like this:

• Manual exploratory testing for new features
• Automated smoke tests for every deployment
• Automated regression tests for critical journeys
• Cross-browser coverage for high-risk workflows
• Analytics and FullStory data used to adjust the browser matrix
• Real browser execution on Windows and macOS for release confidence

This gives teams a practical balance.

Humans investigate. Automation repeats.

How often should you run browser tests?

The answer depends on the importance of the journey.

You do not need to run every test across every browser every time a developer pushes a small change. That can become slow and expensive.

A more practical approach is to use different levels of coverage.

This keeps browser testing useful without turning it into a bottleneck.

For example, your team may run a fast smoke suite on Chrome and Safari for every deployment, then run the larger cross-browser suite on a schedule. If the release touches checkout, billing, login, or a high-value workflow, you may run more browsers before shipping.

The key is to connect test coverage to risk.

How Endtest helps with cross-browser testing

Endtest was built for teams that want reliable end-to-end testing without maintaining their own browser grid, writing fragile test code, or spending hours manually checking the same journeys again and again.

With Endtest, you can create automated tests and run them in the cloud across real browsers on Windows and macOS machines.

That matters because your customers are using real browsers on real operating systems. Your tests should reflect that.

Endtest can help teams test flows such as:

• Signup
• Login
• Checkout
• Form submission
• File upload
• Email verification
• SMS verification
• PDF validation
• Dashboard workflows
• Admin workflows
• Payment redirects
• Visual checks
• Accessibility checks

And because Endtest is no-code, these tests can be understood by QA, developers, product managers, support teams, and business stakeholders.

That is important. Browser testing should not live in a private codebase that only one automation engineer understands.

Endtest also includes AI capabilities that help teams create and maintain tests faster. The AI Test Creation Agent can generate clear, editable Endtest steps, so teams can move faster without turning their test suite into a pile of opaque AI-generated code.

The tests remain standard Endtest tests. They can be reviewed, edited, reused, and executed like any other test.

That is the difference between useful AI and magic that becomes hard to maintain later.

Endtest also offers Unlimited AI, which helps teams use AI across test creation and maintenance without worrying about token limits or credit-based surprises. Combined with unlimited test executions, affordable pricing, strong uptime, and a cross-browser cloud that runs on real Windows and macOS machines, it gives teams a predictable way to scale browser coverage over time.

The browser testing decision tree

If you are not sure where to start, use this simple decision tree.

Step 1: Look at analytics

Ask your Marketing Team for browser, device, OS, and conversion data.

Do not only look at sessions. Look at revenue, leads, signups, trial starts, account activity, and support volume.

Step 2: Identify critical journeys

Make a list of the workflows that must never break.

For most teams, that includes signup, login, checkout, billing, password reset, contact forms, and the main product workflow.

Step 3: Match journeys to browsers

For each critical journey, decide which browser and OS combinations deserve coverage.

A B2B SaaS app may prioritize Chrome and Edge on Windows. An ecommerce site may prioritize Mobile Safari and Chrome on Android. A design tool may care more about Safari and Chrome on macOS.

Step 4: Add real Safari if Safari matters

If Safari users matter to your business, test on real Safari.

WebKit coverage is useful, but it is not the same as real Safari coverage.

Step 5: Automate the repetitive checks

Once a journey is important enough to test repeatedly, automate it.

Manual testing should be reserved for exploration, new feature review, and edge cases that need human judgment.

Step 6: Revisit the matrix every quarter

Browser usage changes. Customer segments change. Your product changes.

Review your analytics and support data regularly. Add or remove browser combinations based on actual risk, not habit.

Common browser testing mistakes

Mistake 1: Only testing in Chrome

Chrome is important, but it is not the whole internet.

A website can work perfectly in Chrome and fail in Safari because of CSS, JavaScript, media, storage, permissions, or form behavior.

Mistake 2: Treating macOS and Windows as identical

Chrome on Windows and Chrome on macOS share a lot, but they are not identical user environments.

If your customers use both, your critical journeys should be tested on both.

Mistake 3: Saying "Safari" when you mean "WebKit"

WebKit is not real Safari.

It is better than ignoring Safari-like behavior completely, but it should not be treated as full Safari coverage.

Mistake 4: Testing pages instead of workflows

A page loading successfully does not prove that users can complete the journey.

Test the full path from intent to outcome.

Mistake 5: Not using analytics

Your browser matrix should not be based only on global market share.

Use your own traffic, conversion, and customer data.

Mistake 6: Leaving browser testing until the end

Browser testing should not be a final pre-release panic.

The most important journeys should be tested continuously, ideally as part of your release process.

FAQ: what browsers should you test?

Should every website test on Safari?

If you have meaningful traffic from macOS, iPhone, or iPad users, yes.

Safari bugs can be costly, especially for ecommerce, SaaS, booking flows, forms, payments, and account workflows.

Is testing on WebKit enough for Safari coverage?

It is useful, but it is not the same as testing on the real Safari browser.

If Safari users matter to your business, real Safari testing should be part of your strategy.

Is headless browser testing enough?

Headless browser testing is useful for fast feedback, but it should not be your only release-quality signal.

Critical journeys should be tested in environments that resemble your real users as closely as possible.

Should you test old browser versions?

Usually, not many.

You should test old browser versions only when analytics, customer contracts, regulated environments, or enterprise requirements show that they matter.

For most teams, testing current and recent browser versions is enough.

Should small teams still do cross-browser testing?

Yes, but they should be selective.

Small teams do not need a huge matrix. They need a smart matrix based on analytics, customer value, and risk.

Start with Chrome, Safari, and the highest-value browser and device combinations from your own data.

Final recommendation

Start with your analytics. Ask your Marketing Team which browsers and devices your visitors, leads, and customers actually use. Look at conversion rates and drop-off points. Use tools like FullStory to understand where users get stuck. Then build a browser matrix around the journeys that matter most.

For most serious websites and web applications, that means testing Chrome, Safari, Edge, and Firefox across the platforms your users actually rely on. It also means testing on real browsers running on Windows and macOS, not only headless browsers or browser engine builds inside Linux containers.

And if Safari matters to your users, test real Safari.

Manual testing can help you spot problems, but it does not scale. The long-term solution is automated cross-browser testing that runs consistently across your critical journeys.

That is exactly where Endtest can help: no-code test creation, cloud execution on real browsers, AI-assisted test creation and maintenance, Unlimited AI, strong uptime, and predictable pricing for teams that want better browser coverage without building and maintaining their own test infrastructure.