User-Agent parser
Paste a User-Agent string and see the structured breakdown: browser, OS, device, engine.
Paste a UA string on the left. Try your own browser's User-Agent via the button below the input.
§ About this tool
What is a User-Agent string?
The HTTP User-Agent header is a text field that every client (browser, mobile app, scraper, CLI tool) sends to identify itself. The format accreted historically rather than being designed: every entry was added because some server-side check rejected clients without it. That is why every modern browser still claims to be every other browser in some way.
A typical UA carries the platform, layout engine, browser version, and a chain of compatibility tokens. Servers parse it for analytics, A/B targeting, bot detection, and legacy feature toggles, none of which is fully reliable, because the field is freely chosen by the client.
How it works
A typical desktop UA reads Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. The Mozilla/5.0 prefix is universal and meaningless. The platform comment names the OS. AppleWebKit/... identifies the layout engine. Chrome/... and trailing Safari/... tokens exist so servers checking for either keep working.
Chrome, Edge, and Safari have begun freezing the version portion of the UA and steering developers toward User-Agent Client Hints (UA-CH) : separate headers like Sec-CH-UA and Sec-CH-UA-Platform.
When to use this tool
- Decoding a UA from a server log to identify the client OS and browser.
- Sanity-checking the UA your application sets on outbound requests (custom CLI tools, cron jobs, SDKs).
- Investigating bot traffic that may be forging a browser identity.
- Building or verifying a UA-based analytics pipeline.
- Reviewing what data your browser exposes when you send a request.
Common pitfalls
- The UA is trivially spoofable.
curl,wget, and every HTTP library lets the caller set any string. Treating the UA as authentication or proof of platform is a mistake. - Version-based feature detection is unreliable. The version reported may be frozen, lied about, or behind a flag. Feature-detect at runtime with
typeof navigator.someAPI, not by parsing a string. - UA parsing libraries lag the real world. New browsers, new mobile devices, and new bot frameworks appear constantly; a static parser will misclassify them.
- Mobile detection by UA is fraught. Foldables, tablets, and desktop mode toggle the platform string. CSS media queries and Client Hints are more reliable for layout decisions.
- UA-CH is opt-in per origin and gated on HTTPS. Code that reads Client Hints needs to send the right
Accept-CHheader on a previous response or the values will be missing.
Frequently asked
Why does Chrome's User-Agent say Safari?
Because Chrome shipped on top of WebKit (and still claims compatibility with it via the trailing Safari/... token) and any server that checked for Safari needed to keep working when Chrome arrived. The token persisted long after the engines diverged.
Should I use User-Agent for feature detection?
No. Feature-detect at runtime by checking whether the API or property exists. UA-based feature detection breaks every time a browser tweaks its string, and it lies about clients that intentionally spoof.
What is User-Agent Client Hints?
UA-CH is a set of headers (Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile) that replace the freeform UA string with structured fields the server explicitly asks for. It is the long-term replacement for parsing UAs.
How do I detect mobile reliably?
Use CSS media queries (@media (pointer: coarse)) for layout, and Sec-CH-UA-Mobile for server-side decisions. UA parsing is the least reliable option.
JWT decoder
Decode, verify, and encode JSON Web Tokens. All in your browser. Nothing leaves the page.
Regex tester
Test regular expressions against JavaScript, Go (RE2), and Ruby (Oniguruma) engines, with live match highlighting and capture-group inspection.
Base64 / URL / hex
Encode and decode between Base64, URL-percent, and hex. UTF-8 safe round-trips.