Why does Chrome's UA string mention Mozilla and Safari?

Historical compatibility. In the 1990s browser wars, servers used UA sniffing to gate features. New browsers had to pretend to be the dominant browser to avoid being locked out. Mozilla/5.0 became the universal prefix; AppleWebKit and Safari got added when Chrome forked WebKit. The modern UA string is essentially a historical scroll of which browsers each new one needed to spoof. Chrome 131 still claims to be Mozilla, AppleWebKit, and Safari for legacy compatibility.

Can users spoof their User-Agent?

Trivially. DevTools has built-in UA override; browser extensions (User-Agent Switcher) make it one click. CLI tools (curl, wget) accept arbitrary UA via flags. So UA strings are never trustworthy for security purposes — bots impersonate browsers, paranoid users impersonate other devices, automated tests pretend to be mobile. Treat UA as a hint, not a fact.

What's UA Client Hints?

A modern alternative to UA sniffing where browsers send minimal info by default (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) and the server explicitly opts in to more detail via the Accept-CH response header. Reduces fingerprinting surface, gives sites consistent structured data instead of parsing strings, and lets browsers freeze the legacy UA string. Chrome and Edge support it; Safari is conservative; Firefox partial.

How do I detect bots?

Multiple signals: known bot UA patterns (Googlebot, Bingbot, AhrefsBot — these self-identify honestly), empty or extremely simple UA strings (suspicious), navigator.webdriver === true (DevTools/Puppeteer/Selenium), absence of expected client hints, mismatched IP and UA combinations, behavior patterns (request rate, lack of mouse movement, no JS execution). UA alone catches honest bots; behavior catches dishonest ones.

Is the UA string changing?

Yes. Chrome since v100 has been progressively reducing UA entropy: minor versions frozen, mobile/desktop architecture unified, Mac OS version frozen at 10.15. Firefox is following similar patterns. The intent: drive adoption of UA Client Hints by making the legacy string less informative. For new code, don't depend on parsed UA for anything beyond rough categorization.

What if my parser doesn't recognize a UA?

New browsers, niche browsers (Brave, Vivaldi, Opera GX), embedded webviews (TikTok in-app browser, Facebook in-app), and uncommon devices may not be recognized by every parser. Most parsers fall back to “Unknown” or reveal the closest match (Brave shows as Chrome because Brave doesn’t advertise itself in UA by default). For comprehensive coverage, use a library like ua-parser-js with regularly-updated regex patterns.

Developer Utilities · Free tool

User Agent Parser

Paste a User-Agent string to parse out the browser, OS, device, and engine details instantly. A free, no-sign-up tool ideal for log analysis, runs fully in your browser.

Updated June 2026

User-Agent string

Found this useful?Email Buy Me a Coffee

What it does

The User-Agent header is one of HTTP's oldest and most-overloaded headers — a single string that every request includes, telling the server what client is asking. A modern Chrome on Windows sends something like “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36” — a string that mentions four browsers (Mozilla, AppleWebKit, Chrome, Safari) for historical compatibility reasons even though it's really just Chrome on Windows. That historical layering started in the early-90s “browser wars” when servers checked UA strings to gate features, forcing every new browser to claim it was also the dominant browser to avoid being locked out.

A user-agent parser breaks the string into its actual components: browser (Chrome, Firefox, Safari, Edge, Opera, Brave) plus version, rendering engine (Blink, Gecko, WebKit, EdgeHTML — though most are now Blink-based), operating system (Windows 10/11, macOS, iOS, Android, Linux) plus version, device type (desktop, mobile, tablet, bot), and architecture (x64, ARM). Useful for log analysis, debugging browser-specific bugs, identifying bot traffic, and confirming what your development device actually identifies as when you’re writing user-agent-aware code.

Important context for 2024+: the User-Agent header is being deprecated for fine-grained identification in favor of User-Agent Client Hints (UA-CH), a structured header system where browsers send only minimal info by default and servers explicitly request additional details via the Accept-CH response header. Chrome already reduces UA string entropy (freezing minor versions, unifying mobile/desktop architecture). For new code, prefer feature detection (testing if a feature exists) over UA sniffing — UA strings can be spoofed, change unpredictably, and don’t reliably reveal capabilities. Use this parser for debugging and log analysis, not as a runtime branching mechanism in production.

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/user-agent-parser" width="100%" height="720" frameborder="0" loading="lazy" title="User Agent Parser" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

How to use it

Paste your User-Agent string into the input box.
Click Parse — the tool extracts browser, OS, device, and engine.
Read the structured breakdown.
Copy individual fields or the full parsed object.
Use for log analysis, debugging, or confirming what your test device reports.

When to use this tool

Debugging a browser-specific bug — confirm the user’s exact browser and version from a bug report.
Analyzing server logs to understand traffic composition by browser/OS/device.
Identifying suspect bot traffic by checking for known bot UA patterns or empty/unusual strings.
Confirming what your test environment reports (mobile emulation in DevTools changes UA).
Building dashboards that segment user behavior by platform.

When not to use it

Runtime feature gating — UA sniffing is fragile; use feature detection (`if ('feature' in navigator)`) instead.
Strict device fingerprinting — UA can be spoofed; for fraud detection, use multiple signals (fingerprinting libraries, server-side checks).
Mobile-vs-desktop layout decisions — use CSS media queries, not UA parsing. Window dimensions are far more reliable.
Blocking bots — most legitimate bots identify themselves correctly (Googlebot, Bingbot); malicious bots spoof common browsers anyway. Use rate limiting and behavior analysis.

Common use cases

Educational use — demonstrating the underlying concept
Onboarding a colleague who needs the same calculation/conversion
Verifying a number or output before passing it on
Quick use during a typical workday

Frequently asked questions

Why does Chrome's UA string mention Mozilla and Safari?: Historical compatibility. In the 1990s browser wars, servers used UA sniffing to gate features. New browsers had to pretend to be the dominant browser to avoid being locked out. Mozilla/5.0 became the universal prefix; AppleWebKit and Safari got added when Chrome forked WebKit. The modern UA string is essentially a historical scroll of which browsers each new one needed to spoof. Chrome 131 still claims to be Mozilla, AppleWebKit, and Safari for legacy compatibility.
Can users spoof their User-Agent?: Trivially. DevTools has built-in UA override; browser extensions (User-Agent Switcher) make it one click. CLI tools (curl, wget) accept arbitrary UA via flags. So UA strings are never trustworthy for security purposes — bots impersonate browsers, paranoid users impersonate other devices, automated tests pretend to be mobile. Treat UA as a hint, not a fact.
What's UA Client Hints?: A modern alternative to UA sniffing where browsers send minimal info by default (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) and the server explicitly opts in to more detail via the Accept-CH response header. Reduces fingerprinting surface, gives sites consistent structured data instead of parsing strings, and lets browsers freeze the legacy UA string. Chrome and Edge support it; Safari is conservative; Firefox partial.
How do I detect bots?: Multiple signals: known bot UA patterns (Googlebot, Bingbot, AhrefsBot — these self-identify honestly), empty or extremely simple UA strings (suspicious), navigator.webdriver === true (DevTools/Puppeteer/Selenium), absence of expected client hints, mismatched IP and UA combinations, behavior patterns (request rate, lack of mouse movement, no JS execution). UA alone catches honest bots; behavior catches dishonest ones.
Is the UA string changing?: Yes. Chrome since v100 has been progressively reducing UA entropy: minor versions frozen, mobile/desktop architecture unified, Mac OS version frozen at 10.15. Firefox is following similar patterns. The intent: drive adoption of UA Client Hints by making the legacy string less informative. For new code, don't depend on parsed UA for anything beyond rough categorization.
What if my parser doesn't recognize a UA?: New browsers, niche browsers (Brave, Vivaldi, Opera GX), embedded webviews (TikTok in-app browser, Facebook in-app), and uncommon devices may not be recognized by every parser. Most parsers fall back to “Unknown” or reveal the closest match (Brave shows as Chrome because Brave doesn’t advertise itself in UA by default). For comprehensive coverage, use a library like ua-parser-js with regularly-updated regex patterns.

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →