BrowserTools
Werbung
Startseite / Netzwerk / User-Agent-Parser

User-Agent-Parser

Zerlege einen User-Agent-String in Informationen zu Browser, Engine, Betriebssystem und Gerät.

Betreut von BrowserTools

User-Agent-Parser wird geladen… Wenn nichts passiert, aktiviere JavaScript.

Der User-Agent-Header ist eine Textzeichenkette im freien Format, die Webbrowser und HTTP-Clients mit jeder Anfrage senden und mit der sie die Software identifizieren, die die Verbindung aufbaut. Obwohl es sich nur um eine einzige Textzeile handelt, kodiert ein gut geformter User-Agent eine erstaunliche Menge an Informationen: die Browserfamilie und -version, die zugrunde liegende Rendering-Engine, das Betriebssystem und dessen Version sowie oft den Gerätetyp oder das Gerätemodell. Diese Informationen waren ursprünglich dafür gedacht, dass Webserver browsergerechte Inhalte ausliefern konnten, zu einer Zeit, als Internet Explorer und Netscape Seiten sehr unterschiedlich darstellten. Heute werden User-Agent-Strings für Analysen, Bot-Erkennung, Funktionserkennung und das Debuggen von Kompatibilitätsproblemen in Webanwendungen genutzt.

Häufig gestellte Fragen

Welche Daten sendet dieses Tool an eure Server?
Keine. Das Parsen des User-Agent läuft vollständig in deinem Browser über eine clientseitige JavaScript-Bibliothek ab. Kein UA-String, den du einfügst oder der automatisch erkannt wird, wird an unsere Server gesendet. Für dieses Tool gibt es keine Backend-Anfragen, also gibt es nichts zu protokollieren oder zu speichern.
Warum enthalten User-Agent-Strings 'Mozilla/5.0' sogar bei Chrome und Safari?
Das ist ein Kompatibilitäts-Altlast, die auf die Browserkriege der späten 1990er-Jahre zurückgeht. Webserver jener Zeit lieferten 'Mozilla'-Browsern reichhaltigere Inhalte und allen anderen abgespeckte Inhalte aus. Um nicht mit abgespeckten Seiten beliefert zu werden, fügte jeder neue Browser unabhängig von seiner tatsächlichen Identität 'Mozilla/5.0' zu seinem UA-String hinzu. Diese Praxis hält seit über 25 Jahren an und ist inzwischen als erwartetes Verhalten in der HTTP-Spezifikation verankert.
Warum stimmt das geparste Ergebnis nicht immer mit meinen Erwartungen überein?
Das Parsen des User-Agent ist von Natur aus heuristisch. Neue Browserversionen, ungewöhnliche Betriebssysteme und benutzerdefinierte UA-Strings von Apps oder Tools können jeden Parser verwirren. Manche Browser geben sich absichtlich falsch aus (Opera meldete sich beispielsweise früher als Internet Explorer). Mobile Apps, die Webansichten einbetten, melden oft ihren eigenen App-Namen zusätzlich zum UA der zugrunde liegenden WebView. Wenn der Parser 'unbekannt' anzeigt, verwendet der UA-String ein unkonventionelles Format, das der Parser nicht zu erkennen gelernt hat.
Was ist der Unterschied zwischen der Browser-Engine und dem Browser selbst?
Die Rendering-Engine (z. B. Blink, Gecko, WebKit) ist der zugrunde liegende Code, der das HTML parst, das CSS anwendet und das JavaScript ausführt. Der Browser ist die auf dieser Engine aufbauende Anwendung, die die Adressleiste, Lesezeichen, Erweiterungen und die Oberfläche hinzufügt. Chrome, Edge, Opera, Brave und die meisten Android-Browser verwenden alle Blink. Firefox verwendet Gecko. Safari verwendet WebKit. Die Engine zu kennen, ist beim Debuggen von Rendering-Kompatibilitätsproblemen oft nützlicher als der Browsername.
Gibt es bei diesem Tool Nutzungsbeschränkungen?
Nein. Da das Parsen vollständig clientseitig in JavaScript läuft, gibt es keine Serveranfragen und damit auch keine Nutzungsbeschränkungen. Du kannst so viele UA-Strings parsen, wie du möchtest, ganz ohne Drosselung. Das Tool funktioniert offline, sobald die Seite geladen ist.
Wie verhält sich das im Vergleich zur Verwendung von navigator.userAgent in JavaScript?
'navigator.userAgent' in der Entwicklerkonsole eines Browsers liefert dir den rohen UA-String dieses Browsers. Dieses Tool macht dasselbe, parst aber zusätzlich den rohen String in strukturierte Felder. Außerdem kannst du damit beliebige UA-Strings aus Protokollen oder anderen Quellen einfügen, was 'navigator.userAgent' nicht kann, da es nur den UA des aktuellen Browsers zurückgibt.
Was sind Client Hints und wie ersetzen sie den User-Agent?
Client Hints (konkret Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile und verwandte Header) sind strukturierte HTTP-Anfrageheader, die die Browseridentifikation in einem maschinenlesbaren Format statt als freie Zeichenkette bereitstellen. Sie wurden von Google im Rahmen der User-Agent-Reduction-Initiative eingeführt, die darauf abzielt, den UA-String auf einen festen Wert mit geringer Entropie zu deckeln, um passives Fingerprinting zu verringern. Server, die detaillierte Browserinformationen benötigen, müssen sie ausdrücklich anfordern, indem sie einen Accept-CH-Header zurückgeben.
Protokolliert dieses Tool User-Agent-Strings für Analysen oder Werbung?
Nein. Da das Parsen vollständig clientseitig erfolgt, werden niemals UA-Daten an unsere Server übermittelt. Es gibt nichts zu protokollieren, mit Werbetreibenden zu teilen oder zu speichern. Dein Browser führt sämtliche Berechnungen lokal durch.
Wie identifizieren sich Bots und Crawler im User-Agent?
Gut funktionierende Bots wie Googlebot (Googles Web-Crawler), Bingbot (Microsoft) und gängige Überwachungsagenten enthalten in ihren UA-Strings identifizierende Tokens, die einer groben Konvention der Form 'BotName/version (+url-mit-infos)' folgen. Bösartige Scraper fälschen oft die UAs legitimer Browser, um der Bot-Erkennung zu entgehen. Zu den Erkennungssignalen jenseits des UA gehören die Anfragerate, das Fehlen einer JavaScript-Ausführung und fehlende browserspezifische Header wie Sec-Fetch-Site.
Kann ich den Betriebssystem- und Geräteinformationen in einem User-Agent vertrauen?
Bei legitimen Browsern auf Standardgeräten sind die Betriebssystem- und Geräteinformationen in der Regel zutreffend, da es für Endnutzer keinen Anreiz gibt, sie zu fälschen. Allerdings kann jeder HTTP-Client einen beliebigen UA-String setzen, Automatisierungs-Frameworks wie Puppeteer und Selenium verwenden standardmäßig den echten Browser-UA, lassen sich aber so konfigurieren, dass sie eine beliebige Zeichenkette nutzen. Datenschutzorientierte Browser und Erweiterungen können den UA bei jeder Anfrage zufällig erzeugen oder fälschen, als Gegenmaßnahme gegen Fingerprinting, wodurch die geparsten Informationen für Sicherheitsentscheidungen unzuverlässig werden.

Über User-Agent-Parser

Webentwickler fügen User-Agent-Strings in Parser ein, wenn ein Fehlerbericht von einem Nutzer auf einer unbekannten Plattform eintrifft und sie genau verstehen müssen, welche Kombination aus Browser und Betriebssystem im Spiel ist. QA-Ingenieure nutzen die geparsten UA-Daten, um zu überprüfen, ob sich ihre automatisierten Testsuiten korrekt identifizieren. Sicherheitsteams analysieren User-Agents in den Serverprotokollen, um Web-Scraper, Schwachstellenscanner und Bots zu erkennen. API-Entwickler prüfen den UA eingehender Anfragen, um zu verstehen, welche Client-Bibliotheken und SDK-Versionen ihre Nutzer einsetzen. DevOps-Ingenieure setzen UA-Daten mit Fehlerraten in Beziehung, um browserspezifische Kompatibilitätsregressionen aufzuspüren.

Dieses Tool parst User-Agent-Strings vollständig in deinem Browser mithilfe einer clientseitigen JavaScript-Bibliothek, es werden keine Daten an unsere Server gesendet. Der aktuelle User-Agent-String deines Browsers wird beim Laden der Seite automatisch erkannt, sodass du dein eigenes geparstes Ergebnis sofort sehen kannst. Du kannst auch jeden beliebigen UA-String einfügen, den du aus einem Serverprotokoll oder einem Fehlerbericht kopiert hast, um ihn bei Bedarf zu parsen. Der Parser ermittelt die Browserfamilie, die Browserversion, die Rendering-Engine (Blink, Gecko, WebKit, Trident), das Betriebssystem, die Betriebssystemversion und die Gerätekategorie (Desktop, Mobilgerät, Tablet, Bot). Die Ergebnisse werden in einem strukturierten Format dargestellt, wobei jedes Feld klar beschriftet ist.

Denke beim Lesen der geparsten Ergebnisse daran, dass die Richtigkeit von User-Agent-Strings nicht garantiert ist, jeder Client kann einen beliebigen UA-String setzen, und das Fälschen ist kinderleicht. Chrome unter Android etwa enthält aus historischen Kompatibilitätsgründen die Tokens 'Mozilla/5.0' und 'Safari' in seinem UA, weshalb rohe UA-Strings selbst bei bekannten Browsern bizarr wirken. Das Projekt des 'eingefrorenen' Chrome-UA (gestartet um 2021) zielt darauf ab, den Informationsabfluss zu verringern, indem die Versionsnummern im UA-String gedeckelt und die detaillierte Browseridentifikation in die strukturierten Client-Hints-Header (Sec-CH-UA-*) verlagert werden. Wenn du eine Browsererkennung für den Produktiveinsatz entwickelst, bevorzuge nach Möglichkeit die Client-Hints-API gegenüber dem Parsen des User-Agent.

Der String, der sich selbst zerbrach: eine kurze Geschichte des User-Agent-Chaos

Der User-Agent-Header wurde 1992 in der ersten veröffentlichten HTTP-Spezifikation eingeführt, ursprünglich als einfache einzeilige Kennung der Software gedacht, die eine Anfrage stellt, etwa 'NCSA_Mosaic/2.0'. Das Chaos begann fast sofort. Als Netscape Navigator 1994 erschien und den Browsermarkt rasch beherrschte, begannen Webentwickler, 'verbesserte' Seiten nur an Netscape auszuliefern, das sich als 'Mozilla' identifizierte. Microsofts Internet Explorer, 1995 veröffentlicht, musste dieselben verbesserten Seiten erhalten und fügte daher 'Mozilla/2.0 (compatible; MSIE 3.0)' zu seinem UA-String hinzu, gab sich also als Mozilla aus und identifizierte sich zugleich als MSIE.

Jeder größere Browser, der folgte, wiederholte dasselbe Muster. Opera fügte Mozilla-Kompatibilitäts-Tokens hinzu. Safari, aufgebaut auf der zu WebKit abgespaltenen KHTML-Engine, fügte 'Mozilla/5.0 (... like Gecko)' zu seinem String hinzu. Chrome, aufgebaut auf WebKit, fügte die Tokens 'AppleWebKit' und 'Safari' hinzu, um sicherzustellen, dass auf Safari ausgerichteter Code auch in Chrome läuft. Das Ergebnis ist, dass ein aktueller Chrome-UA-String unter Windows Tokens für Mozilla, AppleWebKit, KHTML, Gecko und Safari enthält, fünf verschiedene Verweise auf konkurrierende Browser, von denen keiner Chromes eigene Identität ist, die nur als 'Chrome/version' gegen Ende erscheint.

Google kündigte das User-Agent-Reduction-Projekt 2020 an, mit dem Ziel, den UA-String bis 2022 auf einen festen Wert geringer Entropie einzufrieren und die detaillierte Browseridentifikation auf den strukturierten, opt-in-basierten Client-Hints-Mechanismus zu verlagern. Die tatsächliche Einführung verlief langsamer als geplant, und zwar aufgrund von Bedenken zur Webkompatibilität, da Millionen von Webanwendungen für eine Logik, die sich nicht leicht migrieren lässt, auf das Parsen des UA-Strings angewiesen sind. Damit wird der User-Agent-Header zu einem lebendigen Beispiel dafür, wie schwierig es ist, einen fehlerhaften, aber tief verankerten Internetstandard abzuschaffen: Selbst nach drei Jahrzehnten und nahezu allgemeiner Anerkennung, dass das Format kaputt ist, misst sich der Aufwand für seine Ablösung in Jahren.

Verwandte Tools

Wie lautet meine IP, mein User Agent und meine Browser-Infos

Sieh dir deine öffentliche IP-Adresse, deinen User Agent, die Anfrage-Header und die Fähigkeiten deines Browsers an, sofortige Abfrage, kein Tracking.

WHOIS-Abfrage

Frage die WHOIS-Registrierungsdaten jeder öffentlichen Domain ab: Registrar, Daten und Nameserver.
Werbung
Werbung
Werbung