User-Agent Parser: Browser, OS & Gerät erkennen

User-Agent Strings direkt im Browser auswerten: Browser, Betriebssystem, Geräte-Typ und Rendering-Engine werden automatisch herausgelesen. Praktisch für Debugging, Bot-Erkennung und Analytics.

Zuletzt aktualisiert: 17. Februar 2026

Kurz erklärt

Ein User-Agent ist ein Text-String, den Browser, Apps und Crawler bei jeder HTTP-Anfrage automatisch mitschicken. Er beschreibt, welche Software da anfragt: Browser samt Version, Betriebssystem, Rendering-Engine, manchmal auch Gerätetyp.

Ein Beispiel aus dem Alltag: Ein Kollege meldet, ein Formular funktioniere bei ihm nicht. Sie fragen nach dem User-Agent, er schickt Ihnen so etwas:

Mozilla/5.0 (iPhone; CPU iPhone OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1

Schon aus dieser einen Zeile wissen Sie: iPhone, iOS 17.2, mobiler Safari. Sie müssen den Bug also nicht auf Ihrem Desktop-Chrome nachstellen, sondern gezielt in Safari auf iOS testen, wo das Problem tatsächlich auftritt. Genau für solche Momente ist dieser Parser gedacht: String rein, lesbare Antwort raus.

Aufbau eines User-Agent-Strings

Der Aufbau wirkt auf den ersten Blick kryptisch, folgt aber einem festen Muster. Nehmen wir als Beispiel:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Das "Mozilla/5.0" am Anfang ist ein historisches Überbleibsel aus den 90er Jahren und trägt heute keine echte Information mehr. Interessant wird es erst danach:

  • Plattform: "Macintosh; Intel Mac OS X 10_15_7"
  • Rendering-Engine: "AppleWebKit/537.36 (KHTML, like Gecko)"
  • Browser: "Chrome/120.0.0.0"
  • Kompatibilitätsangabe: "Safari/537.36"

Wofür Entwickler den UA-String tatsächlich brauchen

Support-Tickets einordnen

Wie im Beispiel oben: Ein Bug, der "nur bei manchen Nutzern" auftritt, entpuppt sich oft als Problem einer bestimmten Browser/OS-Kombination, etwa Safari auf iOS 15 oder Firefox ab Version 125. Der User-Agent ist meist der schnellste Weg, das einzugrenzen.

Bots von echten Besuchern unterscheiden

Suchmaschinen-Crawler identifizieren sich über ihren eigenen User-Agent, etwa Googlebot, Bingbot, DuckDuckBot, ClaudeBot oder GPTBot. Server-Analytics, Web Application Firewalls und robots.txt nutzen diese Angabe, um Zugriffe zu steuern oder gezielt andere Antworten auszuliefern.

Auswertungen zu Browsern und Geräten

Welche Browser und Betriebssysteme sind bei Ihren Besuchern verbreitet, welche Geräteklasse dominiert? Solche Auswertungen fließen in Entscheidungen wie Mobile-first-Design oder die Browser-Matrix für Tests ein.

Als Notlösung, wenn Feature-Detection nicht reicht

Der sauberere Ansatz in der Webentwicklung ist Feature-Detection, also etwa if ('fetch' in window), statt UA-Sniffing. Bei manchen Device-spezifischen Bugs in älteren Android-Browsern kommt man um einen Blick auf den UA aber trotzdem nicht herum.

Wo der User-Agent an seine Grenzen stößt

  • Fälschbar: Jeder Client kann seinen UA frei setzen. Curl, Playwright und Headless-Chrome tun das ständig.
  • Wird durch Client Hints abgelöst: Chrome und Edge führen mit Sec-CH-UA einen strukturierteren, datenschutzfreundlicheren Header ein.
  • Mobile Systeme frieren die Details ein: iOS 17 und Android 14 reduzieren absichtlich die Detailtiefe, um Fingerprinting zu erschweren.
  • Privacy-Browser verschleiern gezielt: manche senden bewusst generische oder rotierende User-Agents.

Kurz gesagt: Der UA-String ist ein guter erster Hinweis, aber keine verlässliche Identitätsquelle. Für sicherheitsrelevante Entscheidungen sollte er nie die einzige Grundlage sein.

Fingerprinting und Datenschutz

Der User-Agent ist Teil dessen, was man als Browser-Fingerprint bezeichnet. In Kombination mit anderen Signalen wie Canvas-Rendering, installierten Schriftarten oder Zeitzone lassen sich Nutzer auch ohne Cookies über mehrere Sessions hinweg wiedererkennen. Genau deshalb bewegt sich die Browser-Branche weg von ausführlichen UA-Strings hin zu minimalen Headern plus gezielt abrufbaren Client-Hints.

Ein paar Beispiele zum Ausprobieren

  • Chrome Desktop: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
  • Googlebot: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36
  • curl: curl/8.4.0
  • Python-requests: python-requests/2.31.0

Datenschutz

Die Auswertung findet vollständig in Ihrem Browser statt. Es wird kein User-Agent-String an unseren Server übertragen.

Häufige Fragen zum User-Agent

Warum beginnt fast jeder User-Agent mit "Mozilla/5.0"?

Ein Erbe aus den 90er Jahren: Webserver prüften damals gezielt auf "Mozilla" und lieferten unterschiedliche Inhalte aus. Um kompatibel zu bleiben, führt praktisch jeder Browser dieses Präfix bis heute mit.

Kann ich meinen eigenen User-Agent ändern?

Ja. In Chrome geht das über die Developer-Tools unter "More tools" und "Network conditions", auch Browser-Add-ons bieten das an. Tools wie curl, Postman oder Selenium lassen sich ebenfalls mit beliebigem UA konfigurieren.

Reicht der User-Agent, um Bots zuverlässig zu erkennen?

Nein. Der UA allein lässt sich leicht fälschen. Für echte Verifikation, etwa bei Googlebot, empfiehlt sich zusätzlich ein Reverse-DNS-Lookup, wie Google es selbst dokumentiert.

Was sind Client Hints und warum lösen sie den User-Agent ab?

Client Hints sind strukturierte HTTP-Header wie Sec-CH-UA, die Browser-Informationen gezielt und sparsam übermitteln, statt alles in einem einzigen String preiszugeben. Damit lässt sich Fingerprinting erschweren.

Warum sehe ich bei iOS-Geräten oft weniger Detailtiefe im UA?

Apple friert die Versionsangaben im User-Agent bewusst ein, um es schwerer zu machen, einzelne Geräte über die Zeit hinweg wiederzuerkennen. Genauere Angaben zu Modell oder Browser-Build sind darüber nicht mehr zuverlässig zu ermitteln.