| Your Browser | AppleWebKit |
| Browser Version | 537.36 |
| Your OS | |
| User Agent | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) |
What Is My Browser reads the information your web browser sends to every website you visit and displays it back to you in plain language. The moment you load the page, it parses your User-Agent string and a handful of other browser-exposed values, then breaks that raw data into readable fields: browser name and version, rendering engine, operating system, device type, and the full raw User-Agent header itself. Some builds of this kind of tool also surface screen resolution, viewport size, cookie and JavaScript status, and preferred language — details that live in the browser but aren't part of the HTTP headers a server sees by default.
None of this is exotic. Every website you open already receives most of it automatically, on every request, without asking permission. This tool just puts that same information in front of you so you can see exactly what a server, a script, or a piece of analytics software is reading about your setup right now.
The distinction worth keeping in mind is where each piece of data comes from. Browser name, version, engine, and OS are typically derived from the HTTP request headers your browser sends automatically — no JavaScript required. Screen resolution, viewport size, color depth, cookie status, and language preference come from client-side JavaScript running in the page itself, reading properties like window.screen or navigator.language. Both categories describe your browser, but they arrive through different channels, which is part of why a dedicated detection page is more consistent than trying to read this information out of raw server logs by hand.
There's no configuration and nothing to install. The workflow is short:
If you're troubleshooting a rendering bug and the browser you're testing in isn't the one causing the problem for a user, ask that user to open this same page and send you a screenshot or the raw string. It removes the guesswork of "which Chrome" or "which Safari" you're actually dealing with.
It's tempting to assume browser detection is a solved, boring problem in 2026. It isn't, for a few concrete reasons.
"It's broken on my phone" tells a developer nothing actionable. "Safari 17.4 on iOS, iPhone, viewport 390x844" tells them exactly where to start reproducing the issue. A huge share of front-end bugs are engine-specific — a flexbox gap bug in older WebKit, a CSS `:has()` support gap, a JavaScript API that exists in Chromium but not yet in Firefox. Without the exact browser and version, you're debugging blind.
Google Analytics, server access logs, and CDN dashboards all report browser and OS breakdowns, but they're inferring that data from the same User-Agent string this tool reads — and UA strings can be ambiguous, spoofed by extensions, or reduced by newer browser privacy features (more on that below). If your analytics say "12% of traffic is Safari" and a user reports a bug you can't reproduce in Safari, checking their actual reported UA string against what your analytics tool bucketed them as can reveal a mismatch.
Even with evergreen, auto-updating browsers, support for newer CSS and JS features rolls out at different times across Chromium (Chrome, Edge, Opera, Brave), Gecko (Firefox), and WebKit (Safari). Knowing precisely which engine and version a visitor is on lets you cross-reference sites like caniuse-style compatibility tables and know whether a feature you're relying on will actually work for them.
Googlebot, Bingbot, and other crawlers identify themselves with their own distinct User-Agent strings, separate from any real browser. If a site is serving different content, blocking, or redirecting based on User-Agent (a practice that has legitimate uses but is also a common source of cloaking penalties), a tool like this is a fast way to confirm what string a crawler-simulating request would actually present, and to sanity-check your own UA-based rules aren't misfiring on real visitors.
The raw string this tool displays looks cryptic at first glance — something like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36. It reads like a list of browsers you're not using, and that's not a bug — it's decades of backward-compatibility baggage.
Every modern browser's UA string starts with Mozilla/5.0 because, in the mid-1990s, sites checked for that token to decide whether to serve "advanced" HTML features. Every browser since has kept it so it doesn't get treated as a legacy browser. Chrome's string mentions AppleWebKit and Safari because Chrome's rendering engine, Blink, forked from WebKit (Safari's engine) years ago, and countless scripts on the web check for the word "Safari" to detect any WebKit-family browser — so Chrome kept it to avoid breaking those scripts. It's a string built almost entirely out of historical patches, not a clean description of what the browser actually is.
This is exactly why parsing a UA string reliably is harder than it looks, and why a dedicated tool that keeps its detection logic current is more trustworthy than eyeballing the raw text yourself.
| Method | How it works | Reliability today | Best used for |
|---|---|---|---|
| User-Agent parsing | Reads the UA header/string and matches it against known patterns | Good for browser/OS family, weaker for exact minor versions on newer Chromium builds | Quick human-readable summary, bug reports, log analysis |
| Feature detection | Checks whether a specific API or CSS property exists, rather than reading a name string | Very reliable, but only answers "does X exist," not "which browser is this" | Deciding whether to run a polyfill or enable a feature in code |
| Client Hints (`Sec-CH-UA` headers) | Browser opts in to sending structured, low-entropy data on request | Accurate where supported, but not all browsers implement the full set | Modern server-side detection in Chromium-based environments |
| Canvas/font fingerprinting | Infers device characteristics from rendering quirks | Unreliable and increasingly blocked by browsers as a privacy risk | Not recommended for legitimate browser detection |
What Is My Browser relies primarily on the first method — reading and parsing the User-Agent string — because that's the one piece of information every browser still sends by default on every request, no opt-in required.
Most detection confusion comes down to not knowing which engine sits underneath a browser's brand name. It matters because rendering bugs and feature support track the engine, not the brand:
| Engine | Browsers that use it | Typical UA giveaway |
|---|---|---|
| Blink | Chrome, Edge, Opera, Brave, most Android WebViews | Contains "Chrome/" followed by a version number |
| Gecko | Firefox and Firefox-based forks | Contains "Gecko/" with a fixed placeholder date, plus "Firefox/" |
| WebKit | Safari, and all browsers on iOS (Apple requires WebKit for App Store browsers) | Contains "Safari/" without a following "Chrome/" token |
That last row trips people up the most: on iOS, even Chrome and Firefox are required by Apple to run on WebKit under the hood, so a "Chrome for iOS" UA string looks meaningfully different from a "Chrome for Windows" one, and rendering behavior follows Safari's engine, not Chromium's. If a bug reproduces on Chrome for iOS but not Chrome for desktop, the engine difference is almost always the reason.
A few things worth knowing if you use this kind of tool regularly:
This tool reports what your browser tells it — nothing more. A few honest caveats:
Because Chrome's rendering engine, Blink, is a fork of WebKit (Safari's engine), and countless older scripts across the web check for those exact words to decide what a browser supports. Every major browser keeps these legacy tokens in its UA string for backward compatibility, not because it's actually running Safari or Gecko code.
Usually, yes, for most browsers as of today. But Chrome and other Chromium-based browsers have started reducing how much version detail they expose in the standard User-Agent string as part of ongoing privacy changes, so over time some builds may show a less precise minor version unless the tool also reads Client Hints data where available.
Yes. A VPN changes your IP address and apparent location, not your browser's User-Agent string. Browser identification and IP/network identification are two completely separate signals a site can read independently.
No. Private browsing modes prevent your browser from saving local history and cookies; they don't alter the User-Agent string or other browser-reported details that a page can read.
Developers, support teams, and server administrators often need the exact raw string to reproduce a bug, write a server rule, or confirm what a specific piece of software is presenting — the plain-language summary ("Chrome 124 on Windows") is a simplification of that raw string, and some troubleshooting needs the unsimplified version.
Yes. Some privacy and security extensions deliberately modify or randomize the User-Agent string to reduce tracking. If the result looks unusual or inconsistent with the browser you know you're running, a UA-spoofing extension is the most common explanation.