Browser Statistics for Web Devs & QA: Sept Data
This article summarizes the key browser statistics for September that web developers and QA teams should know, covering market share, feature support, and testing priorities. You’ll get the actual numbers for desktop and mobile browsers, plus practical advice on how to use this data in your testing matrix. The focus is on real, checkable data from public sources like StatCounter and Can I Use, as of September 2024.
Why Browser Stats Matter for Your Work
Browser market share tells you where to spend your limited testing time. If a browser has 2% share, a bug there affects a small slice of users; if it has 20%, that same bug is a launch blocker. QA teams use these numbers to build a test matrix—the list of browser/OS combinations you must verify before release. Developers use them to decide which CSS features are safe to use without a fallback, and which need prefixes or polyfills.
September data is particularly useful because it reflects the end of summer release cycles. Major browsers push stable updates in August and September (Chrome, Firefox, Safari, Edge), so the September numbers show the new baseline you’ll support for the next quarter. Also, school and work seasons shift usage patterns—more desktop usage during business hours, more mobile on weekends.
Global Market Share: Desktop and Mobile (September 2024)
According to StatCounter’s public data for September 2024, the global browser market (all platforms combined) looks like this:
- Chrome: ~65% – still the dominant browser by a wide margin.
- Safari: ~18% – driven by iPhone’s default browser (all iOS browsers use WebKit).
- Edge: ~5% – Chromium-based, so it behaves like Chrome in most tests.
- Firefox: ~3% – small but loyal desktop base.
- Opera, Samsung Internet, others: ~9% combined.
On desktop alone, Chrome is around 66%, Edge 13%, Safari 9%, Firefox 7%. On mobile, Chrome leads with ~70%, Safari ~25%, Samsung Internet ~3%. These numbers are global; your own analytics may differ significantly depending on your audience’s geography and industry.
Feature Support: What You Can Safely Use
Market share alone doesn’t tell you if a feature works. For that, check Can I Use (caniuse.com) for the specific feature. As of September 2024, here are a few notable support levels:
- CSS Grid: Supported in all current browsers since 2020 – safe to use without fallback.
- CSS Subgrid: Now supported in Chrome, Edge, Firefox, and Safari (since Safari 16). You can use it for nested grids, but test older Safari versions.
- container queries: Supported in all evergreen browsers since early 2023 – good for responsive components.
- View Transitions API: Supported in Chrome/Edge, but not yet in Firefox or Safari – use only as an enhancement.
- Array.prototype.toSorted() and toReversed(): Supported in Chrome 110+, Edge, Safari 16+, but Firefox only added them in 115 – still not universal.
For QA, the rule is: check caniuse for every new API or CSS property you plan to use. Don’t assume “evergreen� means “all browsers.� Safari updates are tied to macOS/iOS releases, so some users stay on older versions for years.
How to Build a Testing Matrix from This Data
Your QA matrix should cover the browsers that matter to your users, not just the global top three. Here’s a practical approach:
- Pull your own analytics (Google Analytics, Plausible, etc.) for the last 3 months. Filter out bots and internal traffic.
- Include browsers with at least 2% of your sessions – that’s usually Chrome, Safari, Edge, Firefox, and sometimes Samsung Internet or Opera.
- Add the latest two major versions of each browser. For Chrome and Edge, that’s the current and previous stable. For Safari, current and two back (since iOS users update slower).
- Test on real devices for mobile – emulators miss touch events, viewport quirks, and performance issues.
- Prioritize by risk: if you use a cutting-edge feature, test it in all target browsers. If you use only basic HTML/CSS, you can reduce the matrix.
For most projects, a realistic matrix is: Chrome (latest, previous), Edge (latest), Safari (latest, two back), Firefox (latest), plus iOS Safari and Android Chrome on a few real devices. That covers ~95% of typical traffic.
Common Pitfalls When Reading Browser Stats
Three mistakes trip up developers and QA teams:
- Using global stats for a local audience. If your users are in Japan, Safari share is higher; if in Germany, Firefox is higher. Always use your own analytics.
- Ignoring WebView and in-app browsers. Many mobile users browse inside Facebook, Instagram, or other apps that use a system WebView (often older than the standalone browser). Test those if your site gets traffic from social media.
- Assuming “Chrome� means one thing. Chrome on Android is different from Chrome on desktop. Also, Chrome for iOS uses WebKit, not Blink, so it behaves like Safari. Your tests must run on the actual engine, not just the browser name.
How to Read the Numbers: A Worked Example
Say your analytics show 10,000 sessions last month: 6,500 Chrome, 1,800 Safari, 900 Edge, 500 Firefox, 300 other. That’s 65% Chrome, 18% Safari, 9% Edge, 5% Firefox. With a 2% threshold, you’d test Chrome, Safari, Edge, and Firefox. If you had a feature that only works in Chrome, you’d be blocking 35% of users—so you’d either add a fallback or test a polyfill.
For version support, if you see 20% of your Safari traffic is on Safari 15 (released 2021), you must support that version even though it’s three years old. The September 2024 data shows Safari 17 is the current version, but many users are on 16 or 15 due to macOS update reluctance.
Frequently Asked Questions
Q: Should I stop testing Firefox because it has only 3% share?
No. Even 3% of a large user base is thousands of people. Also, Firefox is often used by technical users who might be your power users. If your analytics show Firefox at 1% or less, you can deprioritize, but keep a smoke test.
Q: Why is Safari’s share so high on mobile even though Chrome is the default on Android?
Because in the US and many Western countries, iPhone market share is high. Safari is the default browser on iOS, and Apple requires all iOS browsers to use WebKit, so even Chrome on iOS is Safari under the hood. That’s why iOS Safari is a critical test target.
Q: How often should I update my testing matrix?
Quarterly is a good rhythm. Browser releases come every 4 weeks for Chrome and Firefox, but major version jumps that break sites are rare. Re-evaluate after each major Safari or Chrome release, and whenever you add a new feature that relies on recent APIs.
Q: What’s the difference between StatCounter and W3Counter?
They use different sampling methods and site pools, so numbers vary by a few percentage points. For consistency, pick one source and stick with it. StatCounter is more commonly cited, but W3Counter often shows higher Safari share because it tracks more tech-oriented sites.
Q: Does Chrome’s dominance mean I can ignore other browsers?
No. Even if Chrome is 65% of your traffic, that leaves 35% who might see a broken site. Also, search engines and social media crawlers use various engines, and accessibility tools often rely on Firefox or Safari. A bug in a minority browser can still damage your reputation.
Q: How do I test for browsers I don’t have on my machine?
Use cross-browser testing services (like BrowserStack or Sauce Labs) that provide real devices and browsers in the cloud. For quick checks, you can use Chrome’s DevTools device mode, but that only simulates viewport, not engine behavior. For iOS Safari specifically, you need a Mac with Xcode or a cloud service.
Practical Tips for QA Teams
- Automate where possible: Use Selenium or Playwright to run the same test suite on Chrome, Edge, and Firefox. Safari automation works on macOS only, so plan accordingly.
- Keep a “browser lab� with one machine per major OS (Windows, macOS, Linux, Android, iOS) to manually test edge cases.
- Monitor your own stats monthly – a sudden spike in Safari or a new browser (like Arc) might change your priorities.
- Use feature detection (e.g., @supports in CSS, or Modernizr) instead of browser sniffing. This future-proofs your code.
In summary, September’s browser stats show Chrome’s continued dominance, Safari’s strong mobile presence, and a long tail of smaller browsers. Use your own analytics to refine the global picture, test the latest two versions of each major browser, and always check feature support on Can I Use before using something new. That approach will catch most issues before your users do.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.