User agent: what does your browser tell every website?
How does this check work, and what does the result tell you?
AdminKit shows your browser's raw User-Agent header and a plain-language breakdown of the browser name and version, rendering engine, operating system and coarse device type it implies, parsed entirely in your browser with no server round trip or third-party UA database involved.
Part of the Machine protocols cluster — more tools, guides and terms on machine protocols.
What the result means
Treat this as a hint about the client sending the request, not a security boundary — any software can set an arbitrary User-Agent value.
Next step
Check your public IP, or see the MAC vendor lookup for device-level identification.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up when this result changes? Talk to our team and we'll set it up for you.
How it works and limits
Every request your browser makes includes a User-Agent string naming the browser, rendering engine and operating
system it claims to be, as defined in the
MDN User-Agent header reference. This tool
reads navigator.userAgent in your browser (the same value sent to every site you visit) and parses it with
AdminKit’s own lightweight parser — no server round trip, no third-party UA database.
Reading the result
The raw string is shown first, then a best-effort breakdown:
- Browser name and version — e.g. Chrome 131, Firefox 133.
- Rendering engine — Blink, Gecko or WebKit.
- Operating system — Windows, macOS, Linux, Android or iOS.
- Coarse device type — desktop, mobile, tablet or automated bot.
Limits
- A User-Agent string is whatever the client chooses to send — it is a hint, never a verified fact, and any software can set it to anything.
- Chrome, Edge and other Chromium-based browsers are progressively freezing and reducing User-Agent detail, a change Google documents as User-Agent Reduction, steering sites toward opt-in Client Hints instead — expect this string to carry less information over time, by design.
- This runs entirely in your browser; nothing is sent to AdminKit.
See what a User-Agent string reveals for the fuller breakdown of what each parsed field tells a site, or the glossary entry for User-Agent for the short definition. See how this tool compares to WhatIsMyBrowser.com if you’re deciding between the two, or the wider roundup of free User-Agent parser tools for how it stacks up against UserAgentString.com, User-Agents.net and WhatMyUserAgent.com as well. Your User-Agent is one of several identifiers a site can read about your device and connection — for another, see IPv6 and home devices: why no NAT means a firewall, on what your network address itself exposes.
A User-Agent claiming to be a known crawler, like Googlebot or GPTBot, is just as self-reported as any other value this tool parses — see verifying a crawler’s User-Agent claim with reverse DNS for how to actually confirm one.
Frequently asked questions
Can a site trust the User-Agent string?
No — any client can send an arbitrary User-Agent value, so it is a hint, not a verified fact.
Why are browsers sending less detail in User-Agent now?
Chrome, Edge and others are freezing/reducing User-Agent detail (User-Agent Reduction) and steering sites toward opt-in Client Hints instead, to reduce passive fingerprinting.
Does AdminKit log or store my User-Agent string?
No — parsing happens entirely in your browser using navigator.userAgent; nothing is sent to AdminKit's servers for this tool.
Can two different people have the exact same User-Agent string?
Yes, commonly — anyone running the same browser version on the same operating system sends an identical string. On its own, a User-Agent is a weak fingerprint; it becomes more identifying only when combined with other signals.