A "what browser am I using" check is only as accurate as the fields your browser chooses to expose, and those fields are designed for compatibility, not authentication. The traditional user-agent string is a frozen compatibility blob that may mention Mozilla, AppleWebKit, Chrome, Safari, and other tokens at the same time without meaning that five separate products are running. Modern Client Hints add a structured brand list, but browsers may include a GREASE placeholder to prevent code from assuming a fixed order, and some browsers expose no meaningful brand at all. Platform, mobile hint, language, and cookie setting each report a single narrow fact and do not by themselves prove device type, location, or storage availability. An accurate answer therefore looks like a transparent list of what the browser reports — and an honest fallback when a product name is not exposed — rather than a confident label derived from a brittle string match.
What "accuracy" actually means for a browser check
When you search for a way to check which browser is running, you are usually trying to answer one of three practical questions: am I on a supported browser for a website that is misbehaving, what string should I paste into a support ticket, and is anything in my environment lying about what it is. Accuracy in each of those cases is not the same as "guess the right product name from a long opaque string." It is closer to: show me the exact fields my browser is willing to expose, label each one honestly, and tell me when a label is missing rather than filling it in with a confident guess.
That distinction matters because almost every failure mode of older "what is my browser" pages comes from overreaching. A page that ships a long lookup table of user-agent patterns can still be defeated by string reduction, by browsers that ship their own compatibility tokens, by webviews, by enterprise overrides, by privacy extensions, and by remote browser services. A page that exposes only what the browser itself reports — using navigator.userAgentData when available, falling back to navigator.platform only for the platform label, and always preserving navigator.userAgent, language, and cookieEnabled — trades confidence for honesty. That trade is the most accurate contract a browser-side tool can honestly offer.
Why the user-agent string is an unreliable identity source
The user-agent string started as a way to tell servers which browser engine was talking to them, and it grew historical baggage from there. A modern Chrome-family string can include Mozilla, AppleWebKit, Chrome, and Safari as separate tokens. A Safari string can include Safari, Version, and Mobile. Firefox strings include Gecko and Firefox. None of those tokens, on their own, prove that the listed products are actually installed or running, and the order of tokens is not stable.
Mapping the string to a confident product and exact version requires a maintained parser, an updated table of patterns, and a way to keep up with changes that browser vendors ship several times a year. Even then, the result can be defeated by:
- Spoofing, where a browser or extension rewrites the string deliberately.
- Embedding, where a webview shows a host application's string instead of the user's browser.
- Reduction, where the browser trims the string for privacy and removes the version tokens the parser relies on.
- Frozen values, where enterprise policy locks the string to a known legacy value.
- Remote browser services, where the user is technically on one browser while the server renders pages from another.
Treat the raw user-agent value as an opaque compatibility string. It is useful for support teams and bug reports that ask for it. It is not authenticated identity, and no amount of pattern matching makes it so.
What reported brand lists actually contain
User-Agent Client Hints expose a structured array of brand and version pairs through navigator.userAgentData.brands when a browser implements that interface. Each entry is whatever the browser chooses to put there, in the order the browser chooses. To prevent code from assuming a fixed brand list or order, browsers may include a GREASE-style placeholder designed to look like a real brand but carry no real meaning. The most common placeholder name is the literal "Not A Brand," usually paired with a deliberately nonsense version.
A page that displays the brand list accurately should do two things: preserve the order and content the browser supplied, and filter only that known meaningless placeholder without otherwise reshaping the list. If the browser exposes no meaningful brand — because the interface is absent, because every entry is filtered out, or because the browser simply does not implement Client Hints — the page should say so in plain language rather than invent a result from brittle token order. That is what the "Browser name not exposed" message is for.
The same caution applies to version numbers. A brand entry is one browser-chosen version number, not necessarily the real installed version. A spoofed or reduced browser can hand you whatever version string it likes, and an honest report preserves that value instead of trying to "correct" it.
How to read the platform, mobile hint, language, and cookie fields
Each of these fields carries a narrow meaning that is easy to over-read. The table below summarizes what each field reports and what it does not prove.
| Field | What the browser reports | What it does NOT prove |
|---|---|---|
| Brand list (Client Hints) | Browser-chosen brand and version pairs in browser-chosen order | That the product is actually installed, that the version is real, or that the list is unmodified |
| User-agent string | A historical compatibility string with several embedded tokens | Which browser is running, the exact version, or that the string has not been rewritten |
| Platform | The client-hint platform when available, otherwise navigator.platform | The underlying operating system, the device class, or the install path |
| Mobile hint | A boolean from the client-hint interface when it is supplied | That the browser runs on a phone, that the screen is small, that touch is supported, or any device model |
| Language | navigator.language, the browser's preferred content language | The user's location, account locale, keyboard layout, or content preferences |
| Cookies enabled | The browser's reported cookieEnabled value | That every cookie write will succeed, that any specific site can store a cookie, or that tracking is permitted |
Cookies are worth a closer look because the field is often misread. A true value for cookieEnabled only confirms the browser's general setting. Third-party cookie restrictions, partitioning, private mode, expiration, domain and path rules, consent choices, extensions, and enterprise controls can still block a specific cookie. A tool that reports this field does not create a test cookie, infer tracking availability, or measure storage access.
Using the What Browser Am I Using tool step by step
The page itself is intentionally narrow. It reads fields locally, shows them transparently, and offers one export action. To get a useful report, work through the following steps in order.
- Open the What Browser Am I Using tool in the same browser tab where you are seeing the issue you want to report.
- Review the reported brand list at the top of the report and note when the page honestly says the browser name is not exposed. If you see that message, the browser did not provide a meaningful Client Hint brand and any product name you might guess from the user-agent string below is not authoritative.
- Compare platform, mobile hint, language, cookie setting, and the raw compatibility user-agent string in the remaining sections of the report. Each value is read once when the page loads, so reload the page if your environment changes.
- Select Copy browser report and attach it with reproduction steps when troubleshooting. The export is plain text of the visible values only and does not include any private details beyond what the browser itself chose to expose.
- Do not treat the copied text as authenticated identity. Add the failing URL, the time of the issue, exact reproduction steps, screenshots, your extension state, and whether private mode changes the behavior before you send it to support.
What the report cannot prove
Because every field on the page is read from the browser's own surfaces, the report cannot prove the installed application, the executable signature, the update channel, the security patch level, the device owner, or whether the string has been modified. It also cannot prove feature support. A reported brand alone does not demonstrate that a particular Web API works, that a security feature is enabled, or that the browser meets a vendor's current support list. For a supported-browser decision that matters, use feature detection for the required API and consult the product's own About or update screen.
The page also does not upload, fingerprint, or persist anything on a server. Clipboard access happens only after you select Copy browser report. If your organization uses a remote browser service or a managed device profile, the values shown are the values that profile chose to expose, not a statement about the underlying machine.
When to trust the report, and when to add more context
The report is trustworthy as a record of what your browser told the page. It is not trustworthy as proof of identity or capability. The most accurate way to use it is to attach the copied text to a bug report along with the URL, timestamp, reproduction steps, screenshots, extension list, and a note about private mode. If you want a second opinion on what the fields mean, a companion guide that walks through reading the same fields in more detail is a useful next read; you can find it in the article Browser Version Checker: Read What Your Browser Reports. For a feature-support question, trust feature detection and the browser's own About screen over any third-party label.
That combination — a transparent local report, an honest fallback when a brand is not exposed, and the practical context a human reviewer needs to reproduce the bug — is the most accurate answer a browser-side tool can honestly give.