Find Out What Browser You're Actually Running
Find out exactly which browser, version, and rendering engine you're running. Useful when debugging layout issues, writing up bug reports, or checking whether a CSS feature actually works in the specific version your users have. Everything runs in your browser — no installs, no sign-ups.
Current Browser Information
Browser Name
Unknown Browser
Detected web browser applicationBrowser Version
Unknown
Installed browser release versionOperating Platform
Current operating system environment
Rendering Engine
Unknown
Browser rendering engine categoryBrowser Capabilities & Features
Every browser handles privacy, storage, and network access differently. Knowing what your browser supports helps you figure out why something works in one place and breaks in another.
Cookies Enabled
Whether this browser accepts cookies and session storage.Do Not Track
A privacy setting that asks sites not to track you. Most sites ignore it, but some respect it. Network StatusNetwork Status
Whether the browser has an active internet connection.Browser Language
The language your browser is set to use.User Agent String
The user agent is a line of text your browser sends to every website you visit. It contains details about your browser, OS, rendering engine, and device. Developers use it for debugging, compatibility checks, and figuring out why a layout looks different on one machine than another. It's not always accurate — browsers have been deliberately hiding details in the user agent for years now as a privacy measure — but it's still one of the fastest ways to get a rough picture of someone's setup.
Browser Detector
"It works in my browser" is one of the most common and least useful sentences in a bug report, mostly because "my browser" could mean five different things depending on the version, and the person saying it usually has no idea which one they're actually running. This tool reads your browser's available signals and reports the actual browser name, version number, and the rendering engine underneath it — Blink, Gecko, or WebKit, depending on what you're using.
The reason this matters is that browsers are not monolithic. Chrome 120 and Chrome 124 are different browsers in meaningful ways — different CSS feature support, different JavaScript engine behavior, different defaults for security and privacy settings, different bug fix histories. Safari on iOS and Safari on macOS are the same browser name but sometimes behave differently because Apple ships different WebKit versions across platforms at different cadences. Firefox and Firefox ESR (Extended Support Release) can be months apart in feature support while sharing the same name. The browser name alone tells you almost nothing without the version attached to it.
I've been in situations where a bug was reported as "Chrome bug" and turned out to only affect Chrome versions below 122, where a specific CSS feature was still behind a flag. The fix was already in the current release — the reporter just hadn't updated in a while. Without the version number, that conversation would have gone back and forth for days. With it, we could confirm the fix existed and ask them to update in the same message.
Why the version number is the part that actually matters
A CSS bug that shows up in "Safari" might be specific to Safari 15 and already fixed in Safari 17, or it might be the opposite — introduced in a newer version and absent in older ones. Reporting just "Safari" to a developer gives them almost nothing to work with; reporting "Safari 15.4 on macOS" gives them something they can actually pull up in a testing environment and reproduce directly. Same goes for checking whether a CSS feature you want to use — container queries, :has(), subgrid, whatever's newest this year — is actually supported in the specific version someone's running, rather than assuming based on the browser name alone, which can be misleading if someone's a few versions behind.
The version number also matters because browsers update on different schedules. Chrome ships a new major version roughly every four weeks. Firefox follows a similar four-week cycle. Safari updates with macOS and iOS releases, which means the gap between Safari versions can be months rather than weeks, and users on older operating systems might be stuck on a version that's a year or more behind. When you're debugging a browser-specific issue, knowing whether someone is running the latest version or a version from six months ago changes the entire approach to diagnosis. The same symptom might have different causes depending on the version.
Feature detection gets more reliable when you know the exact version. You can write JavaScript that checks for specific API support, but that still doesn't tell you whether a known bug exists in that version. The version number lets you cross-reference with changelogs, release notes, and bug trackers to determine whether the behavior you're seeing is expected, a known issue, or something genuinely new that needs reporting. Without it, you're debugging blind — you know something is wrong, but you don't know whether it's wrong in general or wrong in this specific version.
The rendering engine is equally important but often overlooked. Most people know that Chrome uses Blink and Firefox uses Gecko, but Safari uses WebKit, and older versions of Edge used EdgeHTML before Microsoft switched to Chromium. The engine determines how CSS is parsed, how JavaScript is executed, how certain APIs behave, and which bugs are likely to appear. A layout issue in Chrome and the same layout issue in Safari might have completely different causes because the two engines handle the same CSS property differently. Knowing the engine narrows down the possible explanations immediately.
Where this gets used
Attaching exact browser details to a GitHub issue instead of a vague description that a maintainer has to ask follow-up questions about before they can even start looking. This is probably the single most common use case. A maintainer sees "Chrome" and has to respond asking for the version. A maintainer sees "Chrome 121.0.6167.85 on Windows 11" and can immediately look up that version's known issues, check the changelog, and start reproducing without any back-and-forth. The difference in turnaround time is significant, especially for open-source projects where maintainer time is limited and every follow-up question delays the fix by days.
Confirming a reported bug is reproducible on a specific, checkable version before spending an afternoon chasing something that might already be fixed upstream. This happens more often than you'd expect. Someone reports a visual glitch that turns out to have been patched two versions ago. Or they report it as a new bug when it's actually a known issue that was documented in the release notes for a version they haven't updated to yet. Either way, the version number is what lets you sort this out quickly instead of duplicating effort.
Or just settling an argument about whether a feature is "supported everywhere." It usually isn't, quite yet, and this at least tells you exactly what you're dealing with on your end. I've been in meetings where someone confidently states that a CSS feature works "in all modern browsers" and someone else says it doesn't work in theirs. The Browser Detector shows them running a version from eight months ago. The feature was added three versions after their current one. The argument resolves immediately — it works in modern browsers, they just aren't running one.
QA teams use this for standardized bug reporting. When two testers report the same visual issue but are running different browser versions, the detector shows you whether they should be seeing the same thing or whether the difference in version explains the discrepancy. This saves time triaging bugs that are actually version-specific issues rather than genuine layout problems.
One thing to know about the numbers you'll see
Newer browsers deliberately limit how much detail they expose through user-agent strings, as part of broader privacy protections often called "user-agent reduction" — this has been an ongoing trend across Chrome, Safari, and Firefox for a few years now. The goal is to reduce browser fingerprinting, where advertisers and trackers identify individual users based on the specific combination of browser, version, OS, and installed plugins. If a version number here looks unusually vague or generic, that's the browser choosing not to share more detail by design — not an error in this tool, and not something that can be worked around from the page's side without the browser's cooperation.
Chrome, for instance, started reducing its user-agent string in 2021, gradually freezing version numbers at lower values and simplifying the platform information. A Chrome browser reporting "Chrome/120" in the user-agent might actually be running Chrome 124, but the string is deliberately truncated for privacy reasons. The Browser Detector tries to extract as much accurate information as possible from the available signals, but when the browser itself has decided to hide certain details, there's no reliable way to recover them from the page's perspective.
This is a tradeoff that benefits users in terms of privacy but makes debugging harder in some cases. The Browser Detector reports what it can determine accurately rather than guessing based on incomplete signals. If a value looks generic, it's because the browser gave it less detail, not because the tool failed to read it. For debugging purposes, the best approach is to pair the Browser Detector output with other tools — the Device Dashboard for viewport and DPR information, manual checks in the browser's developer console, or direct inspection on a known device when exact precision matters.
Popular Browsers and Their Engines
Google Chrome
Runs on Blink. The default browser for most people, whether they chose it or not.Mozilla Firefox
Runs on Gecko. The browser people install when they care about privacy or just want something that isn't Chrome.Apple Safari
Runs on WebKit. Ships with every Mac and iPhone, which means it has a huge user base whether developers like it or not.Microsoft Edge
Also runs on Blink. Switched from Microsoft's own engine to Chromium a few years ago, and most people haven't noticed the difference.Last updated: July 2026 | DevNestTools