Detailed analysis of user agent browser environment | ZeroTools

This tool is an analysis utility that deciphers the "User-Agent" header string sent by web browsers during HTTP requests, and structures and displays environmental information such as the OS and browser type.

In the initial state when the tool is launched, it automatically retrieves the window.navigator.userAgent property of the browser currently being used for access, utilizing React's useEffect hook.

Because the retrieved value is set in the text area and immediately passed to the parsing function, you can first confirm how your own access environment is estimated from the UA string.

The string in the text area can be freely edited by the user. By manually pasting a past User-Agent retrieved from a server access log (e.g., the $http_user_agent field in Nginx's access.log) or an unknown string provided by another user as a bug report, and pressing the "Run Analysis" button, the estimation process for the environmental information based on the input value is executed.

As a point of caution, the analysis is not automatically executed immediately after editing the string in the text area; the analysis result from the previous execution will remain in the report area at the bottom of the screen.

To apply the edits, please press the "Run Analysis" button to update the state. Furthermore, by pressing the "Current Environment" button, you can retrieve the string of your initial state again at any time, resetting the input and performing a re-analysis.

The parsing process for the input string in this tool is executed within the browser using JavaScript string manipulation and regular expression features.

Based on the inputted User-Agent string, it estimates the name of the web browser being used and its major version number. Because modern browsers deliberately include the names of other companies' browsers in their strings to maintain historical display compatibility (as an anti-sniffing measure), simple keyword searches will cause misidentification.

Therefore, the implementation of this tool establishes a specific determination order and exclusion rules using regular expressions.

While lowercased strings are used for determining the name, regular expressions against the original string are used for version extraction.

For example, in the case of Microsoft Edge, identifiers like Chrome and Safari are simultaneously included in the string. This tool prioritizes searching for the "edg" substring first.

If there is a match, it determines the browser name to be "Microsoft Edge" and extracts the numbers following "Edg/" as the version number, though this version extraction does not apply to variants like EdgA or EdgiOS.

Similarly, for Opera, it searches for "OPR" or "Opera". For Google Chrome, it uses "Chrome" or the iOS-specific "CriOS" as keys, but by completing the Edge and Opera determinations first, it establishes a priority order.

However, unknown formats may cause misidentifications. When determining Safari, it ensures that "safari" is included in the string while strictly requiring that strings like "chrome", "crios", and "android" are absent.

Only when these exclusion conditions are met does it adopt the numerical value following "Version/" as the Safari version. For Internet Explorer, it checks for the presence of "msie" or "trident" and tracks the numerical value following "MSIE " or "rv:".

If an unknown string pattern that does not match any of these regular expression rules is inputted, it treats the browser name as "Unknown" and the version as an empty string.

The operating system (OS) and device type determination also depend on specific keywords and regular expression groups contained within the User-Agent string.

In a Windows environment, it first detects "windows" in the string and determines the specific OS name from the regularity of the version number following "Windows NT".

However, even for the latest Windows 11, the specification sends the exact same string "Windows NT 10.0" as Windows 10 in the User-Agent.

Therefore, when this tool matches "windows nt 10.0", it outputs the OS version using the compatible notation "10 / 11". Unique names are applied to prior versions such as Windows 8.1 (NT 6.3), Windows 8 (NT 6.2), Windows 7 (NT 6.1), Vista (NT 6.0), and XP (NT 5.1).

For iOS devices (iPhone, iPad, and iPod), the analyzer inspects the string for the pattern "OS [number]_[number] like Mac OS X" via regular expressions and constructs the version number by converting captured underscores (_) into dots (.).

In the updated English evaluation sequence, iOS detection is evaluated prior to macOS detection—aligning with the Japanese edition—ensuring that iPhone and iPad User-Agents containing "like Mac OS X" are correctly recognized as iOS (such as identifying iOS 17.2, Mobile, and WebKit on default iPhone Safari samples) rather than being mistakenly classified as macOS.

Detection for macOS, Android, Windows, Linux, and Chromecast continues based on standard platform tokens. Because User-Agent strings are entirely self-reported client headers that can be altered or spoofed, this analysis remains a heuristic pattern match rather than authoritative hardware authentication or proof of device identity, and legacy engine token extraction remains in place without claiming all parsing limitations are eliminated.

Device types are classified by categorizing iPad or Android (when mobile is not included) as "Tablet", and iPhone, iPod, or strings containing mobile tokens as "Mobile".

Excluding user agents categorized as bots, the analyzer continues to fall back to a default classification of "Desktop" for any non-empty unknown device string.

However, modern iPadOS devices operating in desktop browsing mode routinely send User-Agent strings identical to desktop Macintosh hardware without tablet indicators, illustrating why deterministic device identification cannot be guaranteed solely through client-reported string inspection.

Users should treat parsed device form factors as indicative estimations rather than absolute verification.

Identifying the rendering engine that draws web pages and executes scripts is an analysis process where the historical complexity of User-Agent strings is most apparent.

Many mainstream modern browsers (Chrome, Edge, Opera, etc.) internally adopt the Blink engine, but the string "AppleWebKit" continues to be written in the User-Agent as a token to maintain past compatibility.

In this tool's implementation, it first checks if "applewebkit" exists within the string. If it exists, the basic policy is to set the engine name to "WebKit" and use a regular expression to extract the number following "AppleWebKit/" as the engine version.

However, as a more in-depth determination, if the target string contains "chrome", "edg", or "opr", and it does not contain keywords indicating an iOS device such as "iphone", "ipad", or "ipod", it infers that the actual rendering engine is "Blink", which was forked (derived) from WebKit.

If this additional condition is met, the tool forcibly overwrites the displayed engine name to "Blink". What is critical here is that the numerical value accompanying AppleWebKit in the raw string (e.g., 537.36) is merely a value attached to the compatibility token and does not represent the measured version of the actual Blink engine.

Therefore, when determined as Blink, the engine version retains this captured AppleWebKit number.

On the other hand, in the case of the "Gecko" engine installed in Firefox and others, the number following "rv:" is adopted as the version, and for Internet Explorer's "Trident" engine, the number following "Trident/" is extracted.

The engine determination in this tool is merely an estimation from the provided string; acquiring additional information using the Client Hints API (UA-CH) or feature detection using JavaScript is not implemented.

Therefore, there is a structural limit to confirming the true engine from a User-Agent that has been intentionally spoofed or shortened by the user.

To distinguish whether an access to a website is made by a human-operated browser or by a bot such as a crawler or an automated script, this tool conducts a search using regular expressions that register specific keyword groups associated with known bots.

The determination list includes crawlers of major search engines like "googlebot", "bingbot", "yandexbot", "baiduspider", and "duckduckbot", as well as scrapers for retrieving link preview information on social networks like "facebookexternalhit", "twitterbot", and "linkedinbot".

Furthermore, it performs case-insensitive (using the /i flag) matching against approximately 20 keywords targeting command-line-based HTTP clients like "curl" and "wget", and site monitoring programs.

If the input string matches any of these keywords, the tool's analysis result classifies the device type as "Bot" and displays a red alert badge stating "Matches Bot-related keyword (Not an authentication)" in the detailed analysis report area.

An extremely important implementation specification here is that this feature "does not guarantee or authenticate that the access is from a legitimate bot." If a malicious attacker or spammer intentionally spoofs their source User-Agent string to something like "googlebot", this tool simply evaluates the text input as is, and will naturally determine it to be a Bot.

Conversely, just because a string is not included in the keyword list does not definitively mean it is an access initiated by human operation.

To intuitively grasp the correspondence between input formats and analysis results in actual usage scenarios, four representative "Sample UA" buttons are provided in advance on the screen of this tool.

When these buttons are pressed, the target sample User-Agent string is automatically populated into the text area, and simultaneously, the analysis process is executed, switching the result report.

The first sample, "Chrome (macOS)", is a string example of Chrome 120 running in a Mac environment equipped with an Intel chip. You can observe the process where the operating system is interpreted as "macOS 10.15.7", and the Blink engine determination logic (which checks for the presence of AppleWebKit, identifies Chrome tokens, and confirms it is not an iOS device) is applied.

Note that Blink engine version extraction continues to return the legacy token structure, and macOS detection logic itself remains unchanged.

The second sample, "Safari (iPhone)", is an example of an iPhone environment running iOS 17.2. It features a string structure unique to Mobile Safari, and the device type is classified as Mobile with the rendering engine identified as WebKit.

Under the updated operating system determination order, iPhone, iPad, and iPod tokens are now evaluated before macOS (matching the Japanese implementation), so this sample is properly classified as iOS 17.2 rather than being prematurely matched as macOS by the legacy "like Mac OS X" substring.

Nevertheless, User-Agent strings remain entirely self-reported client strings that are easily spoofed, meaning they should never be treated as authoritative authentication or hardware proof.

The third sample, "Firefox (Windows)", is an example of Firefox 121 running in a Windows environment. Because it matches "Windows NT 10.0" during operating system determination, the tool's unique compatible notation "Windows 10 / 11" is output.

A notable characteristic of this sample is that the Gecko rendering engine and its exact revision token (rv:109.0) are explicitly parsed and displayed.

Other platforms such as standard Windows and Android follow their established detection rules without modification.

The fourth sample, "Googlebot", is a representative string example of Google's search engine web crawler. Because it matches "googlebot" in the determination list, you can observe the device type being classified as a Bot.

In contrast, any unrecognized non-empty user-agent string still defaults to Desktop within the English analyzer logic, and no claim is made that all device classifications are comprehensively covered.

After understanding the behavior of the tool's extraction and exclusion logic utilizing these fixed samples, please utilize it by pasting raw User-Agent strings extracted from the access logs of the web server you actually operate.

It can be useful for investigating the OS and browser of unknown access sources, and understanding the device trends of users visiting your company's services.