To find out what browser you are using on a laptop, open the What Browser Am I Using tool and read the identity and environment fields supplied by the browser in that tab. It can show reported browser brands and major versions, the platform, a mobile hint when one is supplied, the browser language, whether the browser reports cookies as enabled, and the complete navigator.userAgent compatibility string. Because the report describes the browser making the request, open the tool separately in each laptop browser you want to compare. The result is a transparent view of what the current browser chooses to expose, not an authenticated identity record or proof of the installed application. When the browser does not reveal meaningful brand information, the page says “Browser name not exposed” rather than inventing a product name from a legacy token pattern. For a straightforward check, start with the brand list; for a support case, compare the environment fields and copy the visible report alongside the steps that reproduce the problem.
Check the browser currently open on your laptop
- Open the tool in the browser you want to identify. If several browsers are installed, repeat the check in each one. The result reflects the browser whose tab loaded the page.
- Let the page load, then review the reported brand list. Compare the brand and major-version pairs in the order shown. If the interface provides no meaningful brands, note the honest fallback: “Browser name not exposed.”
- Compare the environment fields. Check the platform, mobile hint, language, cookies setting, and complete raw user-agent string. Read these as values supplied by the browser rather than authenticated facts about you or your laptop.
- Copy the report when troubleshooting. Select “Copy browser report” to export the visible values as plain text, then paste them into the relevant support request or issue report and add reproduction details. For a simple browser-identification task, reading the onscreen result is enough.
This procedure identifies only what the current browser exposes. It does not claim to locate installed programs, authenticate the user, or inspect the laptop beyond the fields supplied by the browser.
Read each part of the report correctly
Each row answers a different question. The brand list is the best starting point for a browser name, while the remaining fields provide context that can help explain browser-specific behavior.
| Field | What the tool shows | Important limitation |
|---|---|---|
| Reported brands | Brand and major-version pairs from navigator.userAgentData.brands when available, after empty names and the meaningless “Not A Brand” placeholder are removed. | The list is browser-supplied information, not an authenticated identity record. |
| Platform | The client-hint platform when available; otherwise, navigator.platform. | It may be reduced, legacy-formatted, frozen, or selected for compatibility. |
| Mobile hint | A boolean mobile value only when the client-hint interface supplies one. | It is not a screen-size guess, device model, touch-capability test, or proof that the browser runs on a phone. |
| Language | The browser-reported navigator.language value. | It may differ from content preferences, physical location, keyboard layout, or account settings. |
| Cookies enabled | The general status reported by navigator.cookieEnabled. | It does not guarantee that every cookie write will succeed. |
| Raw user-agent | The complete navigator.userAgent compatibility string. | It may be changed by extensions, overrides, automation, privacy tools, or other factors and is not authenticated identity. |
Use the brand list to answer the main question, then use the other fields to understand the browser environment. Avoid collapsing the rows into a single overconfident profile: each value has a different source and a different limitation.
Understand the reported brand list
Reported brands come from navigator.userAgentData.brands when the browser implements that interface. The widget removes empty brand names and the intentionally meaningless “Not A Brand” placeholder while preserving the remaining brand and version pairs in the order the browser provides them. A browser may insert a GREASE-style placeholder designed to prevent code from assuming a fixed brand list or order, so the tool does not turn the visible sequence into a guessed single-product answer.
Traditional user-agent strings often contain historical compatibility tokens and several browser names at once. A Chrome-family string can mention Mozilla, AppleWebKit, Chrome, Safari, and other tokens without meaning that five separate products are running. The tool deliberately avoids maintaining a large user-agent pattern table because mapping a legacy string to a confident product and exact version requires a maintained parser and can still be defeated by reduction, spoofing, embedding, or privacy settings.
If the client-hint interface is absent, or if filtering leaves no meaningful brands, the page says “Browser name not exposed.” That message is the correct result for an unavailable value. It is not necessary to mine the raw user-agent for a supposed definitive answer.
Treat platform, mobile, language, and cookie details as context
Platform and mobile hint
The platform label uses the client-hint platform when it is available and falls back to navigator.platform. Both sources can provide a reduced, legacy-formatted, frozen, or compatibility-oriented value. The mobile hint appears only when the client-hint interface supplies a boolean. It does not inspect your screen, identify your device model, test touch support, or determine whether you are physically using a phone.
Language and cookie setting
Language comes from navigator.language, so it can differ from the language of the content you are viewing, your physical location, your keyboard layout, or your account preferences. “Cookies enabled” reflects navigator.cookieEnabled and should be read as the browser’s general reported setting. Third-party cookie restrictions, partitioning, storage access policy, private mode, expiration, domain and path rules, consent choices, extensions, and enterprise controls can still prevent a particular cookie from being stored. The page does not create a test cookie or infer whether tracking is available.
Read the raw user-agent as an opaque string
The raw user-agent is preserved because support teams and bug reports often request it. Treat it as an opaque compatibility string rather than a verified profile. Automation, webviews, privacy tools, proxies, extensions, developer overrides, and remote browser services can change the value. Seeing familiar names in it does not prove that those products are installed or that a particular feature will work.
The report cannot prove the installed application, executable signature, update channel, security patch level, device owner, or whether the string has been modified. It is useful evidence about what the browser reported in the tested tab, but it is not proof of the machine’s complete configuration.
Create a report that support can reproduce
Select “Copy browser report” to export the same visible values as plain text. Attach that copied report to a website issue or support request, then add the context needed to reproduce the behavior:
- The failing URL
- The time of the failure
- The exact steps taken
- Screenshots that show the problem
- The state of relevant browser extensions
- Whether private mode changes the behavior
Present the report as browser-reported environment information, not as authenticated identity. This keeps the diagnosis grounded in what the page actually observed and helps support distinguish a browser-specific issue from a general site problem.
Verify exact version and feature support separately
If an exact supported-browser decision matters, use feature detection for the required Web API and consult the browser product’s own About or update screen. A reported brand alone does not demonstrate support for a particular feature or security state. Browser-reported versions can also be reduced, so the tool’s disclosure is most useful as one part of a broader compatibility check.
Keep the check local and understand the privacy boundary
All fields are read locally after the page loads. Nothing is uploaded, fingerprinted into a server record, or persisted by the widget. Clipboard access happens only after you select “Copy browser report.” The result is therefore a transparent, local inspection of browser-supplied values, with the copied text leaving the page only when you choose to paste or share it.
Related reading: What Browser Am I Using on Mac: Read the Local Report.