June 2025 Browser Market Report

Executive read

June 2025 is best understood as a month of stable browser-family signals and increasingly unstable identity details. Chrome remained the practical baseline for compatibility work, while Firefox continued to matter as a distinct rendering and privacy-sensitive path. On mobile, the more important question was often not which Chromium version appeared in a request, but whether the request came from the system browser, a custom tab, or an application WebView.

This report is an editorial reference for QA, analytics, and engineering teams. It is designed to explain what the public signals can support and where they stop. It is not a live traffic dashboard, a census of every device, or a security classification system.

What the archive signals show

The browser market is easier to read at the family level than at the exact User-Agent level. A large Chrome family can contain desktop browsers, Android Chrome, embedded Chromium contexts, and products that add their own product token. Treating that entire set as one behavior creates false confidence. The family is useful for choosing an initial fixture; it is not enough to explain a failed journey.

The archive therefore pairs broad browser activity estimates with raw User-Agent examples and profile notes. The estimates are directional. They help a team decide which browser families deserve routine coverage, which versions should remain in a regression fixture, and which changes deserve a closer look in first-party telemetry.

Firefox deserves a separate comparison path because its release cadence, privacy defaults, and rendering behavior can expose assumptions that remain hidden in a Chromium-heavy test set. A compatibility matrix that only reports a single browser share number can miss this risk. The useful question is whether the browser family changes the behavior of a journey such as sign-in, upload, payment, redirects, or media playback.

User-Agent drift is a measurement problem

In June 2025, a raw User-Agent string was still valuable evidence, but it was not a permanent identity. Browser vendors can reduce platform details, move information into Client Hints, or report a different value when a page runs inside an application container. Analytics filters built only on a version token can therefore change meaning without a product release on the analytics side.

For a durable measurement rule, record the raw header, the normalized family and version, the request date, and the source of the interpretation. Then document the denominator and bot policy used by the report. A number based on pageviews, active users, sessions, or app-store distribution answers a different question. Mixing those denominators makes a trend look precise while hiding the decision being supported.

The practical rule is simple: use the User-Agent to locate a relevant reference record, then verify the behavior with a capability signal or a controlled journey. Keep the original string beside the parsed result so a later parser update does not erase the evidence that led to the original conclusion.

Mobile WebView deserves its own fixture

The mobile signal most likely to surprise a team is the embedded browser. An in-app browser can share a Chromium family and major version with the system browser while differing in cookie handling, popup behavior, external navigation, file selection, storage, and authentication callbacks. A test that passes in Chrome for Android does not prove that the same checkout or OAuth flow will pass inside a host application.

For QA, the minimum useful comparison is a four-path fixture: the device system browser, a known custom tab, a representative application WebView, and a desktop reference browser. Use the same route and account state where possible. Record the exact failing step, not only the browser label. For checkout, that may be the payment redirect or the return callback. For publishing, it may be the file picker or a popup blocked by the container.

For analytics teams, WebView traffic should be labelled as context with a stated confidence level. It should not automatically be treated as a separate browser market share unless the data source and classification rule support that claim.

Recommended actions for engineering teams

1. Keep a stable desktop Chrome fixture and a current mobile Chrome fixture for the main product journeys.
2. Add Firefox coverage for authentication, layout-sensitive views, file handling, and privacy-related behavior.
3. Add one embedded-browser fixture for each high-risk host application instead of assuming that one WebView represents all apps.
4. Store the raw User-Agent and normalized interpretation together in incident notes and test artifacts.
5. Review analytics filters after browser releases, parser upgrades, and changes to Client Hints collection.
6. Label every market estimate with its period, source, denominator, and limitations.

These actions turn a market reference into a test plan. They also keep the team from using a browser label as an authorization, fraud, or identity decision. User-Agent values can be reduced, overridden, or spoofed. Security controls must remain independent from the header.

Method and limitations

UA Hub compiled this historical brief from public browser market-share reporting, vendor release and User-Agent documentation, app-store or distribution signals, and the site’s reference records. The primary public market-share reference is StatCounter’s browser market share report. Browser-specific identity context can be compared with the Chrome User-Agent guide and official Firefox release notes.

The figures and classifications are directional editorial estimates, not first-party UA Hub telemetry. They may be affected by geography, sampling, device mix, bot treatment, reporting methodology, and changes in browser identity. The June 2025 period should be treated as a historical baseline. Before using it to make a release decision, compare the relevant journey with current first-party data and a current browser fixture.

The next useful question

The next report should preserve the same evidence trail while separating browser family, operating system, and container context more clearly. A single share number is useful for prioritization. The engineering value appears when that number is connected to a reproducible journey, a dated raw sample, and an explicit statement of confidence.