User Agent Generator

QA engineers who need a phone UA in an automated browser test, backend developers reproducing a mobile-only rendering bug from a terminal, and SEO specialists checking what a site returns to Googlebot versus a normal visitor all keep a stash of user agent strings somewhere. Copy-pasting them out of old Stack Overflow answers is how stale Chrome 80 strings end up in production test suites.

This generator holds a curated library of current desktop, mobile, and tablet user agent strings for Chrome, Firefox, Safari, and Edge across every major platform. Filter down to what you need, copy any row, or hit Generate for a random pick, then verify how a parser classifies the string before you wire it into a test.

How user agent strings are structured

A user agent string is a space-delimited list of tokens with parenthesized product comments in the middle. The leading Mozilla/5.0 token is a historical compatibility marker that nearly every browser sends regardless of engine. Inside the parentheses sit the platform tokens such as Windows NT 10.0, Intel Mac OS X, or Linux with an x86_64 identifier, followed by the engine token like AppleWebKit or Gecko.

Chromium browsers append their own product token, Chrome/131.0.0.0, after the shared AppleWebKit token, and Edge and Opera add Edg/ and OPR/ markers on the end so servers can tell them apart from plain Chrome. Firefox uses the Gecko/20100101 Firefox/133.0 form and never includes AppleWebKit. Safari on Apple platforms carries a Version/ token plus a Mobile/15E148 token on phones and tablets.

The generator reads these same tokens when it classifies a string for the verification panel. It checks the Edge, Opera, and Samsung markers before the generic Chrome token, because Chromium-based browsers all contain a Chrome substring and order matters. The Mobile token and the iPhone or Android identifiers decide the device class, while an iPad identifier overrides to tablet.

Before and after: a curl request with a spoofed UA

Input, a request with the default curl user agent:

curl https://example.com/page

User-Agent: curl/8.5.0
→ server returns the bare-bones desktop HTML

Output, the same request with a generated Android Chrome UA:

UA: Mozilla/5.0 (Linux; Android 14; Pixel 8)
    AppleWebKit/537.36 (KHTML, like Gecko)
    Chrome/131.0.0.0 Mobile Safari/537.36

curl -H "User-Agent: $UA" https://example.com/page
→ server returns the mobile template and AMP headers

parse check: Chrome · Android · mobile ✓

Paste the same string into the verification panel above and the classifier reports Chrome on Android as a mobile device, confirming the header will trigger the mobile branch before you send it anywhere.

Who generates user agent strings

Common mistakes with user agent strings

• Using a frozen Windows NT 10.0 token to detect Windows 11. UA reduction froze that token years ago, so every Windows version from 10 onward reports NT 10.0. Detect the real platform through the User-Agent Client Hints API or accept that the header cannot distinguish 10 from 11.
• Matching Chrome before checking for Edge or Opera markers. Every Chromium browser contains the substring Chrome, so a naive substring test classifies Edge as Chrome. Check the Edg, OPR, and SamsungBrowser tokens first, which is the same order this tool uses.
• Forgetting the Mobile token on Android strings. Some Android tablets omit Mobile, and servers often treat its presence or absence as the phone versus tablet switch. When building a test fixture, copy a full known-good string rather than editing tokens by hand.
• Baking a pinned version number into a permanent test. A fixture that requires Chrome/131.0.0.0 exactly will break the moment your headless browser updates. Assert on family and device tokens instead of the full version, or refresh fixtures on a schedule.

Best practices for working with user agents

• 1.Store user agent fixtures in a versioned test data file with the date they were captured, so refreshing them later is a one-file change.
• 2.Match on browser family and device class in assertions rather than exact version strings, which keeps suites green across browser updates.
• 3.Verify any generated string through the parse panel before wiring it into CI, so a typo does not silently test the wrong branch.
• 4.Read the User-Agent Client Hints API docs before building a feature that depends on exact OS versions, because the classic header no longer carries that data.

Frequently asked questions