Why do modern user agents still start with Mozilla/5.0?

It is a compatibility token carried forward from older browser-detection logic. It usually does not mean the browser is Mozilla in the historical sense.

What is the difference between AppleWebKit, Safari, and Chrome tokens?

AppleWebKit usually points to the engine family, while browser-specific tokens such as Chrome or Version and Safari indicate which browser identity is being presented on top of that engine.

Are user agents enough for accurate browser detection?

Not always. They remain useful, but version reduction, spoofing, and compatibility tokens make pure string parsing fragile. Use feature detection and Client Hints when available.

Interactive parser plus guide

How to read a user agent string

Paste any user agent below to inspect it, then use the guide sections that follow to understand why browser strings contain so many strange compatibility tokens.

Paste a user agent

Normalized preview

Example anatomy

A modern desktop Chrome string often looks like this:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.6778.205 Safari/537.36

Mozilla/5.0 Compatibility token kept for historical reasons. It is not a literal browser brand anymore.

Windows NT 10.0; Win64; x64 Platform and architecture hints that suggest the operating system and device class.

AppleWebKit/537.36 Engine-family marker. Chromium browsers still carry this token for compatibility.

Chrome/131.0.6778.205 Browser identity and version marker for Chrome itself.

Safari/537.36 Compatibility tail. It does not necessarily mean the browser is Safari.

Patterns to recognize quickly

Firefox/ usually pairs with Gecko/20100101.
Safari on Apple devices often uses Version/x.y together with Safari/605.1.15.
Edge usually appends an Edg/ token after Chrome-style tokens.
Android tablets often contain Android without the Mobile marker.

Where parsing goes wrong

Compatibility tokens can make one browser look like several browsers at once.
Version reduction means some strings intentionally hide patch-level detail.
Extensions and automation tools can spoof values.
In-app browsers may inject app-specific markers that break naive regex rules.

Modern limitation: Client Hints

Browsers increasingly move detailed information out of the raw user agent string and into User-Agent Client Hints. That means older parsing logic may still be useful, but should not be your only source of truth.

If you are building production-grade browser detection, combine user agent parsing with feature detection, server logs, and Client Hints. If you are debugging quickly, the raw string is still a very practical first step.

Start from the basics

Read the overview if you want the broad definition, common use cases, and reliability limits before diving deeper.

Read the overview

See concrete examples

Compare Chrome, Safari, Firefox, Edge, Android, and iPhone examples before you write parser logic or QA notes.

Open examples

Understand Client Hints

Read the modern follow-up on why the browser-identification model changed and where raw strings still help.

Compare with Client Hints

Compare device-class patterns

Use the mobile-versus-desktop page if you need a tighter explanation of device markers and inference pitfalls.

Compare mobile vs desktop

Why do so many user agents still say Mozilla?

Because old browser-sniffing code expected it. Modern browsers preserve the token for compatibility even though the ecosystem has moved far beyond the original meaning.

Why does Chrome include a Safari token?

Mostly for compatibility with websites that historically looked for WebKit or Safari markers. The browser identity is usually clarified by the Chrome-specific token further along in the string.

Should I parse user agents with exact regex rules only?

Only if you control the use case and can tolerate edge cases. For anything important, combine parsing with broader detection strategies.