User-Agent Parser
See what your user agent is and parse any User-Agent string into its real parts — browser, engine, OS, device type and CPU — with bot and crawler detection for Googlebot, bingbot, curl and more. Your own UA loads automatically. Everything runs in your browser; nothing is sent to a server.
Read from your browser locally; nothing is sent to a server. Parsing runs entirely in your browser.
What this tool is
- A free, in-browser User-Agent parser: on load it shows your own user-agent string and breaks it into browser, engine, OS, device type and CPU architecture.
- Paste any UA string to parse it — covers Chrome, Edge, Firefox, Safari, Samsung Internet, Opera and IE, on Windows, macOS, iOS/iPadOS, Android, Linux and ChromeOS.
- Detects common bots and crawlers (Googlebot, bingbot, curl, GPTBot and more) so an automated client is not mislabelled as a real browser.
- Also surfaces a few related client-side navigator fields — platform, languages, cookies, CPU cores — read locally for the "what is my user agent" use case.
- Everything runs client-side: nothing you paste and nothing read from your browser is ever sent to a server.
What is a user-agent string?
Every time your browser requests a page, it sends a User-Agent header: a single line of text that identifies the browser, its rendering engine, the operating system and sometimes the device and CPU. Servers read it to decide whether to send a mobile or desktop layout, to populate analytics, and occasionally to allow or deny a client. It is one of the oldest and most quoted strings on the web — and one of the messiest.
That mess is historical. In the 1990s, servers sniffed the UA to send frames-capable browsers a richer page, so every new browser started claiming to be Mozilla to qualify. The pretending never stopped: modern Chrome still opens with Mozilla/5.0, claims AppleWebKit and (KHTML, like Gecko), and ends with Safari/537.36 — none of which is literally true. Edge, Opera, Samsung Internet and Brave all add their own token after a Chrome/ token, which is why a naïve parser reports them all as Chrome. A correct parser has to check the most specific signature first — which is exactly what this one does.
How to read one
Work left to right and ignore the legacy prefixes. The parenthesised block carries the platform (Windows NT 10.0, iPhone; CPU iPhone OS 17_5, X11; Linux x86_64) and often the architecture (Win64; x64, arm64). The engine is given by AppleWebKit/537.36 (Blink/WebKit) or Gecko with an rv: version (Firefox), or Trident (Internet Explorer). The real browser is the last brand token with a version — Edg/, OPR/, CriOS/, Firefox/ — falling back to Chrome/ or Version/…Safari/.
Client Hints are replacing it
Because the UA string leaks enough detail (browser, version, OS, platform) to help fingerprint individual users, Chromium has been reducing it — freezing minor version and platform detail — and moving precise values to User-Agent Client Hints (Sec-CH-UA headers and navigator.userAgentData), which a site must explicitly request and the browser can withhold. You will still see a classic UA for years, but expect its detail to get coarser.
User agents in security and recon
- Spoofing is trivial. The UA is a header the client sets freely — curl, Python, headless browsers and devtools all send any value. A request claiming to be Googlebot or a normal Chrome user may be neither.
- Blocking by UA is weak. Allow/deny lists keyed on the user-agent are easily bypassed and easily fooled. Use them for analytics and rough bot filtering, never as an access-control or trust boundary.
- Fingerprinting. The UA combined with platform, languages, fonts and screen metrics builds a device fingerprint that tracks users without cookies — the very reason Client Hints and UA reduction exist.
- Log triage & recon. Parsing UA strings from access logs separates real browsers from scanners, scrapers and automated tooling — a routine first pass when reviewing traffic or investigating an incident.
- Verify bots properly. A UA alone does not prove a crawler is genuine. For Googlebot and friends, confirm with a reverse-then-forward DNS lookup of the source IP, not the string.
Security note: a user-agent is self-reported and unverifiable. It is useful for analytics and layout, but it authenticates nothing — never trust it as proof of who or what a client is.
Frequently asked questions
What is a user agent?
A user agent is a line of text (the "User-Agent" HTTP request header) that a browser, app or script sends to every website it talks to, identifying itself. It typically names the browser and its version, the rendering engine, the operating system and sometimes the device and CPU architecture — for example "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36". Servers use it to adapt responses (mobile vs desktop layouts), gather analytics, and sometimes to allow or block clients. The format is historically messy: nearly every browser still begins with "Mozilla/5.0" and claims compatibility with engines it does not use, for backward-compatibility reasons dating to the 1990s browser wars.
What is my user agent?
This page reads your browser's own user-agent string (navigator.userAgent) the moment it loads and shows it at the top, already parsed into browser, engine, OS and device. That read happens entirely inside your browser with JavaScript — the string is not sent to PlayCISO or any server. You can copy it, or replace it with any other UA string to parse that instead. The same panel also shows a few related navigator values your browser exposes to any site (platform, languages, whether cookies are enabled, logical CPU cores), again read only locally.
Can a user agent be faked or spoofed?
Yes — easily and completely. The user-agent is just a request header the client chooses to send, so any value can be set: browsers offer a device-emulation / "request desktop site" mode, developer tools let you override it, and scripts (curl, Python requests, headless browsers) send whatever string you give them. That is why a user-agent proves nothing about the client's true identity and why blocking or allowing traffic purely by UA string is weak security: a malicious bot can trivially claim to be Googlebot or a normal Chrome user. Treat the UA as a hint for analytics and compatibility, not as an authentication or trust signal.
Are user agents being replaced by Client Hints?
Partly. Chromium browsers have been "reducing" the user-agent string — freezing the OS and browser version detail it exposes — and moving precise capability data to User-Agent Client Hints (the Sec-CH-UA family of headers and navigator.userAgentData), which a server must explicitly request and which the browser can withhold. The goal is to cut passive fingerprinting, since the old UA string leaked enough entropy (browser, version, OS, platform) to help identify individual users. For most parsing you will still see a traditional UA string for years, but expect its version and platform detail to get coarser over time, with Client Hints carrying the precise values when a site asks for them.