User-agent checker — find out what's actually sending the request

paste a user-agent string. find out what's actually sending the request.

what this tool does

Takes a User-Agent string (paste it, or let the tool auto-read it from your current request), parses it, and returns a structured breakdown: browser name and version, rendering engine, OS and version, device type, mobile/desktop, and — the part most parsers miss — whether the UA belongs to a webview or in-app browser, and which one. Identifies TikTok, Instagram (Feed, Reels, Stories), Threads, Messenger, Facebook (FBAN/FBAV), Snapchat, LinkedIn, Pinterest, Twitter/X, Reddit, WeChat, Line, KakaoTalk, and the generic platform webviews (WKWebView on iOS, Android WebView). Also identifies bots (Googlebot, Bingbot, AhrefsBot, all the SEO crawlers) and headless browsers (Puppeteer, Playwright, Selenium with default config).

The output is a JSON-shaped block you can copy into a bug ticket, a log, or a server-side detection rule.

why this matters

User-Agent parsing is one of those problems that looks solved until you actually try to do it well. The popular libraries (ua-parser-js, useragent, bowser) cover the major browsers and stop there. They identify "Mobile Safari" or "Chrome Mobile" correctly, but they don't tell you that the request is actually coming from inside TikTok's webview, which presents as Mobile Safari with a custom suffix the parsers ignore.

For most consumer sites, this distinction doesn't matter. For anyone whose product touches deeplinks, attribution, OAuth, payments, or session-cookie flows, it matters constantly. The TikTok-webview request behaves differently from the Mobile-Safari request in a dozen specific ways — pop-up blocking, custom-scheme handling, cookie-jar isolation, and the universal-link interception. If your parser tells you "Mobile Safari" when the request is actually TikTok webview, every downstream decision based on that fact is wrong.

The checker exists to make that distinction obvious in one paste-and-parse. It's also useful for the broader UA parsing case — bot detection for log filtering, headless-browser detection for fraud prevention, device classification for responsive-design debugging — but the in-app browser branch is what differentiates it from the dozen existing UA parsers.

For the broader context on why in-app browsers behave differently from regular browsers, see the cookies explainer. This tool surfaces the in-app-browser distinction the popular parsers miss.

what you'll see

1. Input. Either: paste a UA string into the textarea, or click "Use my current UA" to auto-read the browser's own UA.

2. Parse button. Click. Result appears immediately.

3. Structured result block. A JSON-formatted output:

   {
     "browser": { "name": "Safari", "version": "17.5", "engine": "WebKit" },
     "os": { "name": "iOS", "version": "17.5.1" },
     "device": { "vendor": "Apple", "model": "iPhone", "type": "mobile" },
     "isMobile": true,
     "isWebView": true,
     "webView": {
       "type": "in-app-browser",
       "host": "TikTok",
       "hostVersion": "34.5.0",
       "platform": "iOS"
     },
     "isBot": false,
     "isHeadless": false,
     "rawUA": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 BytedanceWebview/D Trill/34.5.0 ..."
   }
   

4. Human-readable summary. Underneath the JSON, a one-line plaintext verdict: "iPhone running iOS 17.5.1, inside TikTok's in-app browser version 34.5.0."

5. Detection notes. Which substring of the UA triggered the in-app-browser classification (BytedanceWebview, Instagram 320.0, FBAN/FBIOS, FB_IAB, etc.) — useful for engineers building their own detection.

6. Copy as JSON button. For pasting into logs, tickets, server-side test fixtures.

7. Server-side header inspector (optional). A small block that shows the raw HTTP headers your request sent, including all the Sec-Ch-Ua-* Client Hints — useful for engineers who want to see what the modern Client Hints layer looks like alongside the legacy UA string.

who this is for

Mobile and full-stack developers building any flow that depends on knowing whether a request comes from a real browser or a webview — deeplink handoff, OAuth pop-ups, payment-keychain access, session-cookie behavior.

Server engineers writing log-filtering, fraud-detection, or analytics rules that need to distinguish bot, human, and in-app-browser traffic.

QA engineers building test fixtures across the in-app-browser matrix and needing reference UA strings for each platform/version combination.

Support engineers triaging bug reports that include a UA string and need to immediately identify the actual environment the user was in.

currently in development

We're building this. The core UA parsing builds on existing open-source libraries; the work is the in-app-browser identification layer and the version-tracking — TikTok and Instagram ship new UA strings every few releases, and the detector has to stay current.

Notify me when this validator launches — built by engineers, for engineers.

Get notified →

in the meantime

If you need to parse today:

• WhatIsMyBrowser.com's User Agent parser at whatismybrowser.com/detect/what-is-my-user-agent{rel="nofollow"} is the most comprehensive third-party parser and surfaces in-app browsers for the major platforms.
• ua-parser-js on npm is the default library for browser-side UA parsing. It does not natively identify all in-app browsers; you'll need to layer in-app detection on top (regex on BytedanceWebview, Instagram \d+\.\d+, FBAN/FBIOS, FB_IAB, etc.).
• MDN's documentation on the User-Agent header is at developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent{rel="nofollow"} — useful background on why the UA string is the mess it is, and on the User-Agent Client Hints replacement that Chrome is rolling out.
• Manual: log the UA on your server and grep for known webview substrings. For TikTok: BytedanceWebview or Trill. For Instagram: Instagram \d+. For Messenger: FBAN/FBIOS (iOS) or FB_IAB (Android). For Snapchat: Snapchat. Build a 30-line lookup table and you have 80% of what this tool does.

related

Continue reading:

• Detect TikTok in-app browser by user-agent
• In-app browser cookies, explained
• The in-app browser logged-out problem

Related tools:

• In-app browser detector — the consumer-facing version of this same parsing logic, packaged as a one-click escape tool
• Deeplink tester — uses UA fingerprinting to simulate per-environment deeplink behavior
• AASA validator
• Assetlinks validator

Developer reference:

• /api — linkboo's deeplink API includes in-app-browser detection on every request
• /docs — integration documentation