Analyseur d'en-tête Accept-Encoding

Voici les principaux avantages de l'outil.

• Décodage instantané d'Accept-Encoding : décodez n'importe quel en-tête Accept-Encoding instantanément dans votre navigateur, sans aller-retour serveur et sans attente. L'analyseur traite les valeurs q, détecte les encodages pris en charge et recommande le Content-Encoding optimal à servir en quelques millisecondes.
• Analyseur Accept-Encoding en ligne sécurisé : les données de votre en-tête ne quittent jamais votre appareil. L'analyseur fonctionne entièrement dans votre navigateur : aucun envoi à un serveur, aucune transmission de données, 100 % privé. Sûr pour analyser des en-têtes issus de journaux de trafic de production et d'API internes.
• Détection complète des valeurs q et des encodages : l'analyseur décode tous les encodages standard – GZIP, Brotli (br), Zstandard (zstd), DEFLATE et identity – avec des barres de préférence des valeurs q, des détails de compatibilité des navigateurs et un extrait de configuration Nginx prêt à l'emploi.
• 100 % gratuit à vie : l'analyseur d'en-tête accept-encoding est entièrement gratuit, sans inscription, sans offre premium, sans limites et sans publicité. Analysez un nombre illimité d'en-têtes Accept-Encoding à coût nul, pour toujours.

Voici les scénarios les plus courants.

• Déboguer la négociation de compression HTTP : lorsqu'un serveur ne sert pas de réponses compressées, collez l'en-tête Accept-Encoding de l'onglet Réseau des outils de développement du navigateur dans l'analyseur pour vérifier que le client prend bien en charge GZIP ou Brotli – et confirmer que le serveur lit correctement l'en-tête.
• Diagnostiquer des réponses d'API illisibles : si un client d'API reçoit des données binaires illisibles au lieu de JSON, il reçoit peut-être une réponse compressée qu'il ne peut pas décompresser. Utilisez l'analyseur pour vérifier si l'en-tête Accept-Encoding du client inclut l'encodage envoyé par le serveur.
• Valider la configuration serveur : avant de déployer une nouvelle configuration de compression Nginx ou Apache, utilisez l'analyseur pour vérifier que vos clients cibles (navigateurs, applications mobiles, consommateurs d'API) prennent réellement en charge l'encodage prévu – et obtenez un extrait de configuration prêt à l'emploi.
• Auditer la compression des clients d'API : auditez les en-têtes Accept-Encoding envoyés par vos clients d'API – applications mobiles, SDK et intégrations tierces. L'analyseur montre exactement quels encodages chaque client prend en charge, ce qui vous aide à décider d'activer Brotli ou Zstandard sur vos endpoints.
• Vérifier la compression sur CDN et proxy : les CDN et proxys inverses suppriment ou modifient parfois les en-têtes Accept-Encoding avant de transmettre les requêtes aux serveurs d'origine. Utilisez l'analyseur pour comparer les en-têtes à différents points de votre pipeline et identifier où la négociation de compression échoue.
• Recherche sur la compatibilité des navigateurs : étudiez les algorithmes de compression pris en charge par les différents navigateurs et clients HTTP en analysant leurs en-têtes Accept-Encoding. L'analyseur affiche les pourcentages de prise en charge par navigateur pour chaque encodage, vous aidant à décider quels algorithmes prioriser.

L'en-tête de requête HTTP Accept-Encoding est envoyé par les clients (navigateurs, curl, clients d'API, applications mobiles) pour indiquer au serveur les algorithmes de compression de contenu qu'ils peuvent décompresser. Le serveur lit cet en-tête et choisit le meilleur Content-Encoding pour la réponse – généralement Brotli pour les navigateurs modernes ou GZIP comme repli universel. Notre analyseur d'en-tête accept-encoding analyse cet en-tête, décode chaque jeton d'encodage et sa préférence q, et vous indique exactement quel encodage servir pour une efficacité de compression maximale.

Voici les trois étapes.

1. 1 Collez votre en-tête Accept-Encoding : copiez l'en-tête depuis les outils de développement du navigateur (onglet Réseau → en-têtes de requête), depuis une sortie curl -v ou depuis les journaux d'accès de votre serveur. Vous pouvez coller la ligne complète (nom de l'en-tête inclus) ou seulement la valeur. L'analyseur supprime automatiquement le nom de l'en-tête.
2. 2 Cliquez sur « Analyser l'en-tête » : l'analyseur découpe la valeur de l'en-tête sur les virgules, traite chaque jeton d'encodage et son paramètre q facultatif, puis recherche la compatibilité des navigateurs et les recommandations pour chaque encodage. Tout le traitement se fait dans votre navigateur – aucune donnée n'est envoyée à un serveur.
3. 3 Lisez les résultats et configurez votre serveur : l'analyseur affiche un résumé de prise en charge, l'encodage préféré à servir, une répartition détaillée de chaque jeton avec des barres de valeurs q et un extrait de configuration Nginx prêt à l'emploi pour la combinaison d'encodages détectée.

Voici ce que l'analyseur extrait de l'en-tête.

• Jetons d'encodage : chaque encodage séparé par des virgules dans la valeur de l'en-tête est analysé individuellement – gzip, br, zstd, deflate, identity et le joker (*) sont tous reconnus et décodés avec descriptions et données de compatibilité des navigateurs.
• Valeurs q : le paramètre q= facultatif de chaque jeton indique la préférence du client (0,0 = refusé, 1,0 = préféré). L'analyseur trie les jetons par valeur q et visualise la préférence avec un graphique à barres.
• Encodage préféré : l'analyseur détermine le meilleur encodage unique à servir selon les encodages pris en charge par le client – en privilégiant Brotli devant Zstandard, puis GZIP, puis DEFLATE.
• Extrait de configuration serveur : un extrait de configuration Nginx prêt à l'emploi est généré pour la combinaison d'encodages détectée – repli Brotli + GZIP, repli Zstandard + GZIP ou GZIP uniquement.

La négociation de contenu HTTP est le mécanisme par lequel clients et serveurs s'accordent sur la meilleure représentation d'une ressource. L'en-tête Accept-Encoding est le versant client de la négociation de compression : il liste ce que le client peut gérer. Le serveur répond avec un en-tête Content-Encoding indiquant l'encodage réellement utilisé. Ajoutez toujours un en-tête de réponse Vary: Accept-Encoding lorsque vous servez du contenu compressé : cela indique aux CDN et aux proxys de cache de stocker des versions en cache séparées pour les réponses compressées et non compressées, évitant ainsi un affichage illisible pour les clients qui ne prennent pas en charge la compression.