Skip to main content

User-Agent-Parser

User-Agent-Strings analysieren und Browser, Betriebssystem und Gerät identifizieren.

Geprüft von · Zuletzt geprüft

Den User-Agent-Parser verwenden

  1. Einen User-Agent-String einfügen - der UA des aktuellen Browsers ist als Startbeispiel vorausgefüllt. Jeder UA-String (Desktop, Mobil, Bot, IoT-Gerät) funktioniert.
  2. Auf "Parsen" klicken - das Werkzeug führt eine Regex-basierte Erkennungskaskade aus, die Browsername und -version, Betriebssystemname und -version, Gerätetyp (Desktop, Mobil, Tablet) und Rendering-Engine (Blink, Gecko, WebKit, Trident, Presto) extrahiert.
  3. Die Aufschlüsselung lesen - jedes erkannte Feld erscheint mit dem übereinstimmenden Teilstring, damit du sehen kannst, warum der Parser zu seiner Schlussfolgerung gelangt ist (nützlich, wenn die Erkennung falsch aussieht).
  4. Die rohen Token inspizieren - der Parser zeigt auch den UA-String, der an Semikolons und Klammern aufgetrennt wurde, sodass du herstellerspezifische Ergänzungen erkennen kannst (Produkt-Token, OEM-Identifikatoren, benutzerdefinierte App-Wrapper).
  5. Das normalisierte Ergebnis kopieren - die Ausgabe kann als JSON für Fehlerberichte, Analytics-Abfragen oder Dokumentation kopiert werden.

Wie UA-Parsen funktioniert

Der User-Agent-Header ist ein Klartext-Produktbezeichner-String, definiert in RFC 9110 (HTTP Semantics, Abschnitt 10.1.5) als "eine Folge von Produkt-Token, die die User-Agent-Software und alle signifikanten Unterprodukte identifizieren". In der Praxis ist das Format eine Horror-Geschichte der Abwärtskompatibilität: jeder moderne Browser behauptet, Mozilla/5.0 zu sein, enthält gefälschte Token für Safari/KHTML/Gecko, um Sniffing-Checks auf alten Websites zu bestehen, und hängt seinen tatsächlichen Bezeichner spät im String an. Korrektes Parsen erfordert eine Kaskade von Regex-Tests in einer bestimmten Präzedenzreihenfolge.

Dieser Parser führt geordnete Regeln aus: zuerst Bots prüfen (Googlebot, Bingbot, Slackbot, Dutzende von Crawlern), da ihre Strings deterministischer sind; dann Edge und Opera prüfen, bevor Chrome geprüft wird (weil ihre UAs "Chrome" enthalten); dann Chrome, Firefox, Safari, IE in dieser Reihenfolge prüfen. Die Betriebssystemerkennung folgt einer ähnlichen Kaskade, wobei iPadOS speziell behandelt wird, weil moderne iPads standardmäßig als macOS tarnen. Die Rendering-Engine wird aus dem erkannten Browser abgeleitet, nicht separat geparst. Die gesamte Kaskade läuft in unter einer Millisekunde auf jedem modernen Gerät.

Wann du UA tatsächlich parsen musst

  • Server-Protokolle debuggen, wo ein Kunde eine fehlerhafte Seite sieht - das Parsen seines UA enthüllt den genauen Browser und die Version für die Reproduktion.
  • Analytics-Abfragen in Search Console, PostHog oder Google Analytics, wo du den Datenverkehr nach Browserfamilie oder Gerätetyp aufschlüsseln müsstest.
  • Bot-Erkennung - Suchmaschinen-Crawler (Googlebot, Bingbot) für SEO-Audits identifizieren, legitime Bots von missbräuchlichen Scrapern durch Reverse-DNS-Verifizierung unterscheiden.
  • Kompatibilitätstests - echte UA-Strings aus deinem Datenverkehr in BrowserStack oder ähnliche Dienste einspielen, um die Testabdeckung an die tatsächliche Benutzerverteilung anzupassen.
  • Recherchieren, wie sich eine bestimmte Anwendung (Outlook, Slack Desktop, Electron-Apps) identifiziert, wenn sie Web-Inhalte einbettet.

Grenzfalle beim UA-Parsen

  • iPad täuscht macOS vor - seit iPadOS 13 sendet Safari auf dem iPad standardmäßig einen macOS-UA. Die einzig zuverlässige iPad-Erkennung ist navigator.maxTouchPoints > 1 auf der Clientseite; serverseitig kannst du ein iPad anhand des UA allein nicht von einem MacBook unterscheiden.
  • Chromes UA-Einfrierung (User-Agent Reduction) - seit Chrome 101 (2022) begann Google, die UA-Granularität zu reduzieren, Nebenversionen einzufrieren und Betriebssystemversionen zu runden. Feingliedrige Versionserkennung bei Chromium erfordert jetzt User-Agent Client Hints.
  • Datenschutzorientierte Browser - Brave, Tor Browser und DuckDuckGo senden absichtlich generische UAs, um Fingerprinting zu reduzieren. Sie anhand des UA allein zu identifizieren ist by design unzuverlässig.
  • WebViews in mobilen Apps - Facebook Messenger, Instagram und TikTok In-App-Browser hängen Bezeichner wie FBAN/FBIOS, Instagram oder musical_ly an. Diese sind nicht standardisiert, aber parsbar.
  • Gefälschte UAs - Entwicklerwerkzeuge in jedem Browser ermöglichen UA-Spoofing, und Befehlszeilenwerkzeuge (curl -A) senden beliebige Strings. Behandle UA als nicht vertrauenswürdigen Hinweis, niemals als Sicherheitsgrenze.
  • Bot-Flotten, die echte Browser imitieren - anspruchsvolle Scraper senden realistische Chrome-UAs. UA allein kann einen echten Benutzer nicht von einer Playwright-gesteuerten Chrome-Instanz unterscheiden; zusätzliche Signale (TLS-Fingerabdruck, HTTP-Header-Reihenfolge, Verhaltensmuster) sind erforderlich.

Der User-Agent-Header und sein Ersatz

RFC 9110 formalisiert die Syntax des UA-Headers, aber der Inhalt entwickelte sich durch Marktdruck über 30 Jahre Browser-Kriege. Jeder Browser behauptet Mozilla/5.0, um 1990er Netscape-Sniffing zu bestehen; jeder WebKit-basierte Browser behauptet KHTML-Erbschaft; jeder Chromium-basierte Browser behauptet Safari-Kompatibilität; Edge behauptet Chrome. Das Ergebnis ist ein String, der über fast alles lügt, außer über sein tatsächliches Produkt-Token, weil das Entfernen eines Anspruchs irgendwo im Web ein altes Skript brechen würde.

Der Ersatz ist User-Agent Client Hints (UA-CH), ein W3C-Entwurf, der seit 2020 in Chromium eingesetzt wird. Anstelle eines monolithischen Strings verwendet UA-CH anforderungsbezogene Header wie Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform und Sec-CH-UA-Full-Version-List (nur gesendet, wenn über Accept-CH angefordert). Firefox und Safari haben UA-CH noch nicht übernommen; sie verlassen sich weiterhin auf den traditionellen Header.

Alternativen und Bibliotheksauswahl

Für serverseitiges Parsen ist ua-parser-js (MIT-lizenziert, 11 Mio. wöchentliche Downloads) der de-facto-JavaScript-Standard. Für Python umschreibt ua-parser die von der Community gepflegte uap-core-Regex-Liste. Für Bot-Erkennung konzentriert sich isbot auf Crawler. Dieser Parser verwendet einen reduzierten Regelsatz, der für Browser optimiert ist, die du im 2026-Datenverkehr tatsächlich siehst; für erschöpfende historische Abdeckung ist ua-parser-js gründlicher. Für Bedrohungserkennung (Scraper, Credential-Stuffer) reicht UA-Parsen allein nicht aus - kombiniere es mit TLS-Fingerprinting (JA3/JA4) und Verhaltensanalyse.

Häufig gestellte Fragen

Kann ich dem User-Agent vertrauen?

Nein. Der UA-Header wird vom Client gesetzt und kann beliebig sein. Die Entwicklerwerkzeuge jedes Browsers enthalten einen UA-Spoofing-Schalter, <code>curl -A</code> akzeptiert jeden String, und automatisierter Datenverkehr gibt sich routinemäßig als Chrome aus. UA ist ein nützlicher Hinweis für Analytics und progressives Enhancement; er ist niemals eine Sicherheitskontrolle. Verwende ihn für Content-Negotiation (mobile Layouts ausliefern) und aggregierte Analytics; verwende ihn nicht für Autorisierung, Missbrauchsprävention oder Feature-Gating, das die Sicherheit betrifft.

Warum sieht Chromes UA aus, als ob er alles vortauscht?

Historische Abwärtskompatibilität. In den 1990er Jahren schnupperten Websites nach "Mozilla", um modernes HTML auszuliefern. Der IE setzte "Mozilla/4.0 (compatible; MSIE...)" davor, um zu bestehen. Safari beanspruchte KHTML und Gecko. Chrome beanspruchte Safari. Edge beanspruchte Chrome. Das Entfernen eines Anspruchs würde ein 25 Jahre altes Skript irgendwo im Web brechen.

Was sind User-Agent Client Hints?

UA-CH ist ein W3C-Nachfolger für den UA-Header, der in Chromium ausgeliefert wird. Er teilt den UA in Header (<code>Sec-CH-UA</code>, <code>Sec-CH-UA-Mobile</code>, <code>Sec-CH-UA-Platform</code>) auf, die Server über <code>Accept-CH</code> anfordern. Hochentropische Daten werden nur gesendet, wenn sie explizit angefordert werden. Chrome, Edge und Opera implementieren UA-CH; Firefox und Safari nicht.

Wie unterscheide ich iPad von Mac anhand des UA?

Das geht nicht zuverlässig. Seit iPadOS 13 (2019) sendet Safari auf dem iPad standardmäßig einen macOS-User-Agent, um sich mehr wie "Desktop-Safari" zu verhalten. Die Workarounds sind clientseitig: prüfe <code>navigator.maxTouchPoints</code> (iPads haben >1, Macs haben 0), prüfe <code>navigator.platform</code>, oder prüfe auf iPadOS-spezifische APIs. Serverseitig ist iPad- und macOS-Datenverkehr anhand des UA allein nicht zu unterscheiden; verwende Accept-CH, um den Hinweis <code>Sec-CH-UA-Platform</code> anzufordern, wenn iPadOS im Scope ist (noch experimentell für iPads speziell).

Was ist der Unterschied zwischen Blink, WebKit und Gecko?

Drei Browser-Rendering-Engines mit unterschiedlicher Herkunft. WebKit wurde 2001 von Apple aus KHTML (dem KDE-Motor) gegabelt und betreibt Safari. Blink wurde 2013 von Google aus WebKit gegabelt und betreibt nun Chrome, Edge, Opera, Brave, Samsung Internet und alle Chromium-basierten Browser. Gecko wurde ab 1997 von Mozilla von Grund auf neu gebaut und betreibt Firefox. Die alten Engines Trident (IE) und EdgeHTML (altes Edge) sind ausgestorben, außer in extremen Unternehmensbereitstellungen.

Wie genau ist die Versionserkennung?

Die Browser-Versionserkennung ist für Chrome, Firefox, Edge und Safari auf die Hauptversion genau, da alle ihre Versionsnummer eindeutig im UA enthalten. Die Genauigkeit bei Nebenversionen hat bei Chromium seit Chromes User-Agent-Reduction-Projekt (Chrome 101) abgenommen, das Nebenversionen aus Datenschutzgründen auf einen statischen Wert einfriert. Für genaue Versionsdaten bei modernem Chromium verwende UA-CH's <code>Sec-CH-UA-Full-Version-List</code>.

Kann ich Googlebot zuverlassig erkennen?

Teilweise. Googlebots UA enthält ein klar identifizierendes "Googlebot"-Token. Aber UAs können gefälscht werden, daher erfordert eine echte Erkennung eine Reverse-DNS-Verifizierung: Löse die IP zu <code>*.googlebot.com</code> oder <code>*.google.com</code> auf, dann schlage die IP vorwärts wieder nach. Google dokumentiert dies unter <code>developers.google.com/search/docs/crawling-indexing/verifying-googlebot</code>.

Warum wurde eine mobile App UA-Parsen einschliessen?

In-App-Browser (Instagram-Webview, Facebook Messenger, Slack Desktop) müssen sich identifizieren, damit der von ihnen geladene Web-Inhalt sich anpassen kann. Der Webview-Anbieter hängt Token wie <code>FBAN/FBIOS</code>, <code>Instagram 280.0</code> oder <code>Slack/4.29.149</code> an den UA an. Web-Inhalte erkennen diese, um Funktionen zu vermeiden, die im Webview kaputt gehen (z.B. muss der OAuth-Fluss oft im externen Browser und nicht im In-App-Browser geöffnet werden).

Sendet der Parser meinen UA an einen Server?

Nein. Das Parsen ist eine reine Funktion von Regex-Übereinstimmungen mit dem Eingabe-String. Die Preact-Komponente nimmt deinen UA, führt Regex-Tests aus und rendert das Ergebnis - kein HTTP-Request wird ausgeführt. Du kannst den UA einer internen Unternehmensanwendung einfügen, ohne befürchten zu müssen, dass er an Dritte durchsickert.

Was soll ich verwenden, wenn ich jeden historischen UA abdecken muss?

Die Community-gepflegte Bibliothek <code>ua-parser-js</code> auf npm ist die umfassendste Open-Source-Option mit regelmäßig aktualisierten Regex-Regeln, die Tausende von Browsern, Betriebssystemen und Geräten abdecken, einschließlich längst eingestellter. Für Python verwendet das <code>ua-parser</code>-Paket dieselbe zugrunde liegende uap-core-Regex-Datenbank. Dieses Werkzeug optimiert für Browser und Crawler, die du im 2026-Datenverkehr tatsächlich siehst; für erschöpfende historische Abdeckung verwende eine Bibliothek.

Was ist mit UA-Parsen in SSR- oder Edge-Runtimes?

Regex-basiertes Parsen funktioniert identisch in Node.js, Deno, Cloudflare Workers, Vercel Edge und Bun. Für SSR-Frameworks parse den eingehenden <code>User-Agent</code>-Header serverseitig, um gerätespezifische Layouts vorab zu rendern und Hydrations-Verschiebungen zu vermeiden.

Lohnt es sich, UA-Parsen noch zu lernen?

Ja, mit schrumpfendem Anwendungsbereich. UA-CH und der traditionelle UA koexistieren vorerst - Chromium sendet beide, Firefox und Safari nur UA. Neue Systeme sollten beides akzeptieren, und beliebte Bibliotheken verarbeiten beide. Behandle UA-Parsen als stabile Fahigkeit mit sich schrittweise verbessernden Alternativen.

Verwandte Tools

Mehr Developer Tools

AI Token Counter

Count tokens for GPT-4o, Claude, and Gemini models instantly.

Open tool

Base64 Encoder & Decoder

Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.

Open tool

Bulk URL Encode / Decode

Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.

Open tool

chmod Calculator

Calculate and convert Unix file permission modes between octal and symbolic.

Open tool

Code Screenshot

Create beautiful code snippet images with customizable themes.

Open tool

Color Converter

Convert colors between HEX, RGB, HSL and CMYK formats.

Open tool
ZeroUtil unterstützen