Accept-Encoding-Header-Analysator

Das sind die wichtigsten Vorteile des Tools.

• Sofortiges Dekodieren von Accept-Encoding: Dekodieren Sie jeden Accept-Encoding-Header sofort in Ihrem Browser – kein Server-Roundtrip, kein Warten. Der Analysator parst q-Werte, erkennt unterstützte Kodierungen und empfiehlt das optimale Content-Encoding in Millisekunden.
• Sicherer Accept-Encoding-Analysator online: Ihre Header-Daten verlassen nie Ihr Gerät. Der Analysator läuft vollständig in Ihrem Browser – keine Server-Uploads, keine Datenübertragung, 100 % privat. Sicher für die Analyse von Headern aus Produktions-Traffic-Logs und internen APIs.
• Vollständige Erkennung von q-Werten und Kodierungen: Der Analysator dekodiert alle Standardkodierungen – GZIP, Brotli (br), Zstandard (zstd), DEFLATE und identity – mit Präferenzbalken für q-Werte, Details zur Browser-Kompatibilität und einem gebrauchsfertigen Nginx-Konfigurationsausschnitt.
• 100 % kostenlos für immer: Der Accept-Encoding-Header-Analysator ist völlig kostenlos – ohne Anmeldung, ohne Premium-Version, ohne Limits und ohne Werbung. Analysieren Sie unbegrenzt viele Accept-Encoding-Header kostenlos, für immer.

Das sind die häufigsten Szenarien.

• HTTP-Kompressionsverhandlung debuggen: Wenn ein Server keine komprimierten Antworten liefert, fügen Sie den Accept-Encoding-Header aus dem Netzwerk-Tab der Browser-DevTools in den Analysator ein, um zu prüfen, ob der Client tatsächlich GZIP oder Brotli unterstützt – und ob der Server den Header korrekt liest.
• Unleserliche API-Antworten diagnostizieren: Wenn ein API-Client unleserliche Binärdaten statt JSON erhält, bekommt er möglicherweise eine komprimierte Antwort, die er nicht dekomprimieren kann. Prüfen Sie mit dem Analysator, ob der Accept-Encoding-Header des Clients die vom Server gesendete Kodierung enthält.
• Serverkonfiguration validieren: Bevor Sie eine neue Nginx- oder Apache-Kompressionskonfiguration deployen, prüfen Sie mit dem Analysator, ob Ihre Zielclients (Browser, mobile Apps, API-Konsumenten) die geplante Kodierung tatsächlich unterstützen – und erhalten Sie einen gebrauchsfertigen Konfigurationsausschnitt.
• API-Client-Kompression auditieren: Auditieren Sie die Accept-Encoding-Header Ihrer API-Clients – mobile Apps, SDKs und Drittanbieter-Integrationen. Der Analysator zeigt genau, welche Kodierungen jeder Client unterstützt, und hilft Ihnen zu entscheiden, ob Sie Brotli oder Zstandard für Ihre API-Endpunkte aktivieren.
• CDN- und Proxy-Kompression überprüfen: CDNs und Reverse-Proxys entfernen oder verändern Accept-Encoding-Header manchmal, bevor sie Anfragen an Origin-Server weiterleiten. Vergleichen Sie mit dem Analysator Header an verschiedenen Punkten Ihrer Request-Pipeline und erkennen Sie, wo die Kompressionsverhandlung scheitert.
• Browser-Kompatibilität recherchieren: Recherchieren Sie, welche Kompressionsalgorithmen verschiedene Browser und HTTP-Clients unterstützen, indem Sie ihre Accept-Encoding-Header analysieren. Der Analysator zeigt Unterstützungsprozentsätze pro Browser für jede Kodierung und hilft Ihnen, die richtigen Algorithmen zu priorisieren.

Der HTTP-Request-Header Accept-Encoding wird von Clients (Browsern, curl, API-Clients, mobilen Apps) gesendet, um dem Server mitzuteilen, welche Inhaltskompressionsalgorithmen sie dekomprimieren können. Der Server liest diesen Header und wählt das beste Content-Encoding für die Antwort – typischerweise Brotli für moderne Browser oder GZIP als universeller Fallback. Unser Accept-Encoding-Header-Analysator parst diesen Header, dekodiert jedes Kodierungstoken und seine q-Präferenz und sagt Ihnen genau, welche Kodierung Sie für maximale Kompressionseffizienz senden sollten.

Das sind die drei Schritte.

1. 1 Accept-Encoding-Header einfügen: Kopieren Sie den Header aus den Browser-DevTools (Netzwerk-Tab → Request-Header), aus einer curl -v-Ausgabe oder aus Ihren Server-Access-Logs. Sie können die vollständige Header-Zeile (inklusive Headername) oder nur den Wert einfügen. Der Analysator entfernt den Headernamen automatisch.
2. 2 Auf „Header analysieren“ klicken: Der Analysator teilt den Header-Wert an Kommas, parst jedes Kodierungstoken und seinen optionalen q-Parameter und schlägt Browser-Kompatibilität und Empfehlungen für jede Kodierung nach. Die gesamte Verarbeitung läuft in Ihrem Browser – es werden keine Daten an einen Server gesendet.
3. 3 Ergebnisse lesen und Server konfigurieren: Der Analysator zeigt eine Unterstützungsübersicht, die bevorzugte zu sendende Kodierung, eine detaillierte Aufschlüsselung jedes Tokens mit q-Wert-Balken und einen gebrauchsfertigen Nginx-Konfigurationsausschnitt für die erkannte Kodierungskombination.

Das extrahiert der Analysator aus dem Header.

• Kodierungstoken: Jede durch Kommas getrennte Kodierung im Header-Wert wird einzeln geparst – gzip, br, zstd, deflate, identity und der Platzhalter (*) werden mit Beschreibungen und Browser-Unterstützungsdaten erkannt und dekodiert.
• q-Werte: Der optionale Parameter q= an jedem Token gibt die Client-Präferenz an (0,0 = abgelehnt, 1,0 = bevorzugt). Der Analysator sortiert die Token nach q-Wert und visualisiert die Präferenz mit einem Balkendiagramm.
• Bevorzugte Kodierung: Der Analysator ermittelt die einzige beste zu sendende Kodierung basierend auf den unterstützten Kodierungen des Clients – mit Priorität Brotli vor Zstandard vor GZIP vor DEFLATE.
• Server-Konfigurationsausschnitt: Für die erkannte Kodierungskombination wird ein gebrauchsfertiger Nginx-Konfigurationsausschnitt erzeugt – Brotli + GZIP-Fallback, Zstandard + GZIP-Fallback oder nur GZIP.

HTTP-Content-Negotiation ist der Mechanismus, mit dem sich Clients und Server auf die beste Repräsentation einer Ressource einigen. Der Accept-Encoding-Header ist die Client-Seite der Kompressionsverhandlung – er listet auf, was der Client verarbeiten kann. Der Server antwortet mit einem Content-Encoding-Header, der angibt, welche Kodierung tatsächlich verwendet wurde. Fügen Sie beim Ausliefern komprimierter Inhalte immer einen Vary: Accept-Encoding-Response-Header hinzu – er weist CDNs und Caching-Proxys an, getrennte Cache-Versionen für komprimierte und unkomprimierte Antworten zu speichern, und verhindert unleserliche Ausgaben für Clients ohne Kompressionsunterstützung.