About this User Agent Finder
DigitalDomainKit's User Agent Finder shows the User-Agent request header received by the site and summarizes a few basic details parsed from that header. It is useful when you need to confirm what a browser, crawler, testing tool, mobile app webview, proxy, or command-line client is actually sending to this website during a request. The page also displays the Accept-Language header sent with the same request, so you can see the language preference string that reached the server.
This is a request-header inspection tool, not a browser identity service. The server reads the headers on page load, stores them in the Livewire component state for the current rendered page, and displays the original user-agent string in a copyable textarea. The parser then applies simple pattern checks for common browser, operating system, device, and bot tokens. That makes the result quick and transparent, but it also means the page should be used as a diagnostic snapshot rather than an authoritative browser-detection guarantee.
How to use the tool
- Open the User Agent Finder page from the browser or client you want to inspect.
- Review the textarea at the top of the tool. It contains the exact user-agent string that DigitalDomainKit received in the request.
- Use the Copy button beside the textarea if you need to paste the user-agent string into a support ticket, bug report, test fixture, log comparison, or browser-compatibility note.
- Read the Browser Info card for the parsed browser name and browser-version token detected from the string.
- Read the System Info and Device Info cards for parsed operating system, version, desktop/mobile/tablet, and mobile or tablet flags.
- Read the Additional Info card for bot detection, the request's language preference header, and the parsed platform value.
- If you are testing another browser, device, extension profile, crawler, or command-line client, load the page again from that environment. The values come from the new request, not from a manual input box.
What the page reads from the request
The Livewire component initializes from two incoming request headers. First, it reads User-Agent and displays that string directly in the textarea. Second, it reads Accept-Language and shows that value in the Language row. If either header is missing, the page falls back to an empty user-agent string or Unknown for language. No separate lookup service, browser extension, device database, or client-side fingerprinting script was found in the inspected implementation.
The User-Agent header is part of HTTP request metadata. MDN describes it as a string that can identify the requesting application, operating system, vendor, and version, while also warning that user-agent-based browser detection is often fragile. The current HTTP Semantics specification likewise defines User-Agent as product identifiers and comments supplied by the requesting user agent. In practice, browsers may reduce or freeze parts of the string for privacy, and non-browser clients can set almost any value they want.
The Accept-Language header is separate from the user-agent string. It communicates language and locale preferences such as en-US,en;q=0.9. DigitalDomainKit now reads that header from the request itself rather than trying to find language text inside the user-agent string. That distinction matters because most modern user-agent strings do not contain the browser's full language preference list.
Displayed fields
The visible results are organized into four cards. The table below explains what each displayed field means in this implementation and how cautious you should be when interpreting it.
| Field | How this tool derives it | Important caveat |
|---|---|---|
| User agent string | Read from the incoming User-Agent request header and printed in the textarea. |
Clients, proxies, automation tools, and privacy features can alter or omit it. |
| Browser | Matches common tokens including Chrome, Firefox, Safari, Edge, Opera or OPR, MSIE, and Trident. | The order is simple: a Chromium-based browser with both Safari and Chrome tokens may be classified by the first matching pattern. |
| Browser version | Extracts versions from tokens such as Chrome/, Firefox/, Safari/, Edge/, Opera/, or MSIE. |
It does not currently parse every modern variant token, such as all Chromium Edge Edg/ patterns. |
| Operating system | Looks for Windows, Macintosh or Mac OS X, Linux, Android, iPhone, iPad, or iPod tokens. | Some strings contain overlapping tokens, and browser privacy reduction can hide precise platform details. |
| OS version | Extracts common version fragments from Windows NT, Mac OS X, Android, or iOS-style OS tokens. |
Reported versions may be compatibility tokens rather than the exact installed OS version. |
| Device type | Returns Mobile if the string contains Mobile, Tablet if it contains Tablet, otherwise Desktop. |
Tablets and webviews may not use those exact words, so device class can be wrong or too broad. |
| Is mobile / Is tablet | Boolean checks for Mobile and Tablet tokens. |
A phone browser in desktop mode or a custom app webview may not produce the expected flag. |
| Is bot | Checks for words such as bot, crawler, spider, robot, or crawling. | Legitimate crawlers may use different strings, and spoofed clients can pretend to be bots or humans. |
| Language | Displays the incoming Accept-Language header. |
It is a preference hint from the request, not proof of the user's location, nationality, or spoken language. |
| Platform | Uses similar token checks to OS detection and returns Windows, Mac, Linux, Android, iOS, or Unknown. | It is a broad label and may differ from the hardware, emulator, compatibility layer, or actual device model. |
Example result
During review, the page was tested with a crafted request header:
User-Agent: DDKProbe/1.0 (O'Neil <tag>)
Accept-Language: en-US,en;q=0.9The page returned HTTP 200 and displayed the user-agent string in the textarea. Because the string did not include common browser or operating-system tokens, the parser reported Unknown for browser, browser version, operating system, OS version, and platform, Desktop for device type, and No for mobile, tablet, and bot. The Language row displayed en-US,en;q=0.9, confirming that the field came from the request's language header rather than from text inside the user-agent string.
The same test also checked the copy button markup. The rendered copy handler encoded the apostrophe and angle brackets as JSON-safe unicode escapes, so a value such as O'Neil <tag> did not break the inline JavaScript attribute. In the visible page state, the same characters were HTML-escaped. That is the expected behavior for a page that displays and copies request-header text supplied by a client.
Parser limits and browser-identification caveats
User-agent parsing is inherently approximate. The current implementation uses regular expressions rather than a maintained database such as a commercial device-detection feed or a full open-source parser. It does not make network calls to enrich the result. It does not inspect JavaScript APIs such as navigator.userAgentData, screen size, installed fonts, canvas output, WebGL, timezone, battery state, media devices, or other fingerprinting signals. That restraint keeps the tool simple, but it also limits what it can infer.
Several real-world cases can produce surprising output. Chromium-based browsers often include compatibility tokens such as Mozilla, AppleWebKit, Chrome, and Safari even when the product is not Safari. Safari version parsing can return the WebKit-style Safari/ token rather than the human-facing browser version if the string also contains a separate Version/ token. Newer Microsoft Edge commonly uses Edg/, while this inspected parser checks the older Edge/ pattern. Android tablets may include Mobile, omit Tablet, or request desktop sites. Bots, monitors, link unfurlers, and command-line tools may use custom strings that do not follow browser conventions.
For those reasons, do not treat the result as a browser-identification guarantee. It can help you compare what a request says, understand why a website may be serving a particular variant, or provide a reproducible header string to a developer. It should not be used alone for security access control, fraud detection, licensing decisions, analytics truth, legal identity, or device eligibility rules. A user agent is self-reported request metadata, and any client capable of sending HTTP requests can usually change it.
Copy behavior
The Copy button copies the current user-agent string shown in the textarea. It does not copy the parsed card fields as a report, and it does not let you edit and reparse a custom string inside the page. The textarea is populated from the server-side request header when the page renders. If you need to test a different string, send a new request with that header by using another browser, a browser developer tool override, a proxy, a crawler, a testing client, or a command-line request.
The copy implementation was specifically reviewed because request headers can contain characters that are awkward inside HTML and JavaScript contexts. The current Blade view passes the user-agent value through JSON escaping before embedding it in the inline copy handler. That protects the copy action from common quote and angle-bracket breakage in the rendered markup. As with any copied diagnostic value, review the string before sharing it publicly, because it may reveal browser family, coarse operating system details, application identifiers, or testing infrastructure names.
Privacy and fingerprinting notes
This page does not need to run a full fingerprinting audit to show your user agent. The inspected implementation reads headers already sent as part of the page request. It does not upload a local file, does not ask for device permissions, does not enumerate fonts, does not draw a canvas fingerprint, and does not perform a client-side hardware scan. However, the request necessarily reaches the DigitalDomainKit server, because the page is being loaded from the site. Standard web-server logs, CDN logs, security filters, analytics, or error tooling may record request metadata according to the site's operational configuration.
User-agent and language headers can contribute to browser fingerprinting when combined with other signals. MDN notes that user-agent information has privacy implications, and the HTTP specification discusses privacy expectations around sending complete language preferences. Modern browsers may reduce user-agent detail, limit language lists, or provide settings that change what is sent. If you are checking privacy exposure, use this page as one small piece of evidence: it shows the header values visible to this site for this request, not everything a website, extension, ad script, or anti-abuse service could potentially learn.
Troubleshooting
| Problem | Likely cause | What to try |
|---|---|---|
| The browser is shown as Unknown. | The header does not contain one of the parser's recognized browser tokens. | Copy the full string and inspect it manually, or test with a browser known to send Chrome, Firefox, Safari, Edge, Opera, MSIE, or Trident tokens. |
| The browser name looks too generic. | Many browsers include compatibility tokens from other browser engines. | Use the raw string for support work and avoid relying only on the parsed Browser label. |
| The language is Unknown. | The request did not include an Accept-Language header, or an intermediary removed it. |
Check browser language settings, privacy settings, proxy behavior, or the headers sent by your test client. |
| A tablet appears as Desktop or Mobile. | The parser only checks for broad Mobile and Tablet text tokens. | Read the full user-agent string and compare it with the device or browser documentation. |
| A crawler is not marked as a bot. | The bot check is based on a small set of words such as bot, crawler, spider, robot, and crawling. | Do not use this page as bot verification. Verify important crawlers through their official documentation and reverse-DNS guidance where applicable. |
The copied value differs from a JavaScript value such as navigator.userAgent. |
The page displays the HTTP request header received by the server, while JavaScript APIs are read inside the browser after page load. | Compare both values and consider proxy, extension, browser-reduction, or client-hint behavior. |
Related tools
Use What Is My Browser when you want a more user-facing browser summary. Use Browser Fingerprint Audit when you want to see additional client-side signals beyond request headers. Use Whats My IP to compare the visible network address with browser-header details. Use IP Information for a broader IP lookup.
Editorial and technical notes
This page is built and maintained by Digital Domain Kit. The inspected implementation is a Laravel Livewire component that reads User-Agent and Accept-Language from the incoming request, parses the user-agent with regular expressions, and renders the result in cards below the textarea. The repaired behavior was last tested on September 16, 2026 with a crafted user agent containing an apostrophe and angle brackets plus Accept-Language: en-US,en;q=0.9. The test confirmed HTTP 200, safe copy-handler escaping, and the language header displayed on the page.
References: MDN User-Agent header reference, MDN Accept-Language header reference, and RFC 9110 HTTP Semantics. To report a problem with this tool or its documentation, use the DigitalDomainKit contact page.