You can identify what browser you're using in about ten seconds by reading the brand and version pair that the page already has access to through the User-Agent Client Hints interface, or by checking the navigator.userAgent compatibility string that every modern browser exposes to the page it is currently loading. What Browser Am I Using gathers those locally reported fields without trying to match them against a brittle user-agent pattern table. It shows the reported brand list with the "Not A Brand" GREASE placeholder filtered out, the platform, a mobile hint when the browser provides one, the language, whether the browser says cookies are enabled, and the raw user-agent string itself. When the browser does not publish a meaningful brand, the page honestly says "Browser name not exposed" instead of guessing from an opaque token. Each of those fields is read on your device after the page loads; nothing is uploaded to a server. The result is a transparent view of what your browser chooses to tell a web page about itself.
What What Browser Am I Using Actually Reports
The page does not score, rank, or judge your browser; it lays out the same information that any other JavaScript on the same page could read. It collects a small set of locally available fields and arranges them in one block so you can scan them quickly. The reported brand list comes from navigator.userAgentData.brands when the browser implements Client Hints, and the page shows each brand and major version in the order the browser supplied them. The platform label falls back to navigator.platform when Client Hints does not expose one. A mobile hint appears only when the Client Hints interface supplies a boolean, and it is deliberately not inferred from screen size, touch capability, or device model. The language label is read from navigator.language. The cookie status reflects navigator.cookieEnabled. The full navigator.userAgent string is preserved verbatim because support teams and bug-report templates still ask for it. A Copy browser report button packages those exact visible values into plain text that you can paste anywhere.
How to Identify What Browser You're Using Right Now
- Open What Browser Am I Using in the same browser window you want to identify, since the report describes whatever browser is actually rendering the page.
- Read the reported brand list at the top. If multiple brand and version pairs appear, that is the order your browser chose to publish; the GREASE-style "Not A Brand" placeholder has already been filtered out for you.
- Note the platform, mobile hint, language, and cookie status underneath the brand list so you can confirm whether the device and account context match what you expected.
- If the brand list is empty and the page says "Browser name not exposed", the browser did not publish a meaningful name to script, so do not paste a guessed product name into your support ticket.
- Select Copy browser report and paste the plain text into the support form, bug report, or chat box. Add the failing URL, the time, the exact steps to reproduce, your extension state, and whether private mode changes the behavior.
- For an exact supported-browser decision, run a feature detection for the API you need in your own code, or open your browser's About or update screen rather than relying on the brand label alone.
Reading the Brand List and Client Hints Honestly
The reported brand list is not the same as the historical navigator.userAgent string, even though both come from the same browser. Client Hints were introduced so that browsers could publish a small, deliberate list of brand and version pairs instead of a long compatibility string with leftover tokens from earlier browser generations. A Chrome-family string, for example, can still mention Mozilla, AppleWebKit, Chrome, Safari, and other tokens without meaning that five separate products are running on your machine. The same is true in reverse: a token order can be reduced, spoofed, embedded by a webview, frozen by a developer override, or shifted by a privacy tool. Mapping those strings to a confident product and exact version usually requires a maintained parser, and even then can be defeated by anything that controls the client.
The page filters the GREASE-style "Not A Brand" placeholder, which is designed to prevent sites from assuming a fixed brand list or fixed order, and preserves the remaining pairs exactly as the browser supplied them. This is the most honest read of what your browser chose to expose today. Treat the long legacy string as a compatibility fallback for debugging only and treat the brand list as the authoritative product label for scripts that respect Client Hints. Both views are kept side by side so you can see what your browser publishes and what the raw compatibility string contains.
What Each Reported Field Means (and What It Doesn't)
A useful way to remember the limits of any browser-reported field is to compare what each one actually identifies against what people sometimes assume it proves. The table below summarizes the contract of each field based on what the browser chooses to expose, not on what the page infers from it.
| Field | What it actually shows | What it does not prove |
|---|---|---|
| Reported brands | Brand and version pairs from navigator.userAgentData.brands, with the meaningless "Not A Brand" placeholder removed | The installed application, its update channel, security patch level, or feature support for any specific Web API |
| Platform | The Client Hints platform when available, otherwise navigator.platform | The actual OS kernel, hardware model, signed executable, or that the value has not been modified |
| Mobile hint | The boolean that navigator.userAgentData.mobile supplies when the interface exists | That the device is a phone, that it supports touch, the screen size, or the device model |
| Language | navigator.language for the current document | Keyboard layout, physical location, content preferences, account language, or the browser UI language |
| Cookies enabled | navigator.cookieEnabled, the browser's general cookie setting | That any specific cookie will be written, since third-party restrictions, partitioning, private mode, consent, extensions, and policy can each block a write |
| Raw user-agent | The full navigator.userAgent compatibility string, preserved verbatim | Authenticated identity, the full installed version, that the string is unmodified, or that every named browser is actually installed |
When the Tool Says "Browser Name Not Exposed"
Some browsers do not implement Client Hints at all, and some expose only a placeholder brand list that filters down to nothing meaningful. Rather than parsing the legacy navigator.userAgent into a claimed product and exact version, the page reports "Browser name not exposed" so that you do not paste a brittle guess into a support ticket. In that situation the raw user-agent string is still preserved on screen and included in the copied report, and you can pass it to a support team that maintains its own parser.
For end-user identification in that case, the most reliable next step is to open the browser's own About or update screen, where the vendor prints the exact installed product name and version number. A vendor-printed name overrides any pattern-based guess because it comes from the application itself. Treat the page's honest fallback as a feature, not a limitation: it means the tool is admitting uncertainty instead of overstating what the browser was willing to reveal, and that makes the report more trustworthy when the brand list does contain meaningful labels.
Why "Cookies Enabled" Is Not a Guarantee
The Cookies enabled row reflects the boolean that navigator.cookieEnabled returns, which is the browser's general claim that the cookie feature is on. It does not, by itself, tell you whether any specific cookie write will succeed. Third-party cookie restrictions in private mode, storage partitioning in recent browser versions, consent dialogs that gate advertising or analytics cookies, expiration rules that have already passed, domain and path limits, installed extensions that block tracking, and enterprise policy or managed device settings can each prevent a specific cookie from being stored even when the general setting says cookies are on.
The page intentionally does not create a test cookie, run a sample write, or infer tracking availability from the boolean. That choice keeps the report a faithful read of what the browser says, rather than a claim about what a particular site can do. If you need to know whether a specific cookie can be written on this browser, perform the write in your own code, observe the response, and capture any same-site, secure, or partitioning rules that apply to that domain.
Attaching the Report When You Contact Support
A copied browser report is most useful when it travels with the missing context that support teams need to act on it. The page only exports what was visible on screen, so the rest of the bug report has to come from your notes. Include the failing URL, the time you reproduced the problem, the exact steps you took, whether you were in private or incognito mode, and which browser extensions were enabled at the moment of the failure. If a specific feature needed to be present, such as WebRTC, WebGPU, Service Workers, IndexedDB, or a particular CSS property, feature-detect the relevant API in your own code and quote the boolean result rather than asking support to infer it from the user-agent string alone. Screenshots and short screen recordings usually close the gap faster than any text report.
For a closer read of what the reported fields imply about supported features and how to interpret the brand list in context, the browser version checker guide walks through the same reported fields in more depth and pairs each one with the questions support teams typically ask next.