User Agent Parser & Checker

Parse browser, OS, device, and bot signals

User-Agent input
User-Agent strings can be spoofed or hidden by clients. Use the result for debugging, not as an authentication, authorization, or security boundary.
Parsed result
Client / container appChrome147.0.7727.15
BrowserChrome147.0.7727.15
Rendering engineBlink537.36
Operating systemWindows10/11
Device typeDesktop
BotNoUnknown
Raw User-AgentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/147.0.7727.15 Safari/537.36

Tool guide

About User Agent Parser & Checker

User-Agent Parser breaks a request User-Agent string into browser, version, rendering engine, operating system, device type, and common bot clues.

Parsing runs locally in the current browser, which makes it useful for reading logs, traffic sources, compatibility reports, and crawler requests.

How to use User-Agent Parser

  1. Paste a User-Agent string from logs or request headers.
  2. Inspect browser, OS, device, engine, and bot signals as the input updates.
  3. Copy the raw UA or JSON result when you need to share the finding.

When you would use it

  • Identify clients from Nginx, CDN, or application logs.
  • Debug compatibility issues for mobile Safari, Chrome, Edge, and similar browsers.
  • Spot common crawler strings such as Googlebot or Bingbot before deeper verification.

UA detection limits

A User-Agent is self-reported by the client, so it can be spoofed, shortened, or hidden. Modern browsers also reduce UA detail over time, so the result is a debugging clue, not proof.

  • Do not use UA parsing as authentication, authorization, or a security boundary.
  • Browsers on iOS are usually constrained by WebKit, so UA details may not fully match product branding.
  • Bot detection is heuristic; critical decisions should use reverse DNS, IP ranges, or official platform verification.

User-Agent Parser FAQ

Is my User-Agent uploaded?
No. Parsing runs locally in your browser and is not uploaded to wetool.site.
Why does it show Unknown?
The UA may be non-standard, privacy-reduced, rewritten by a proxy, or not covered by the lightweight rules.
Can it prove a bot is real?
No. UA strings are easy to fake; real crawler verification needs the provider’s official method.

User-Agent and Client Hints

Client Hints replace some UA detail, but logs and older systems still store User-Agent strings. A parser remains useful for historical logs and browser compatibility debugging.

UA spoofing and security boundaries

A User-Agent is just text sent by the client. Browser extensions, command-line clients, proxies, test scripts, and crawlers can all rewrite it.

  • curl -A and browser devtools can spoof a UA, so do not use UA parsing for login, authorization, payment risk, or admin access decisions.
  • UA parsing is useful for compatibility debugging, log grouping, rough analytics, and support triage; security decisions need server-side sessions, permissions, signatures, and stronger device signals.
  • To verify Googlebot or Bingbot, use reverse DNS followed by forward lookup confirmation instead of trusting the UA string alone.

User-Agent vs Client Hints migration map

Chromium is reducing detail in the legacy UA string and moving more information behind opt-in Sec-CH-UA request headers.

  • Browser brand and major version: Chrome/126 maps to Sec-CH-UA and Sec-CH-UA-Full-Version-List.
  • Platform: Windows, Android, or iPhone in the UA maps to Sec-CH-UA-Platform.
  • Mobile detection: Mobile in the UA maps to Sec-CH-UA-Mobile, but servers must request hints with Accept-CH first.

Common crawler UA tokens

These tokens are useful starting points for log investigation, but they do not prove crawler identity by themselves.

  • Googlebot
  • Bingbot
  • DuckDuckBot
  • Baiduspider
  • YandexBot
  • facebookexternalhit
  • Twitterbot
  • Slackbot-LinkExpanding
  • AhrefsBot
  • SemrushBot