Analisador de cabeçalho Accept-Encoding

Estas são as principais vantagens da ferramenta.

• Decodificação instantânea de Accept-Encoding: decodifique qualquer cabeçalho Accept-Encoding na hora no seu navegador - sem ida e volta ao servidor e sem espera. O analisador processa valores q, detecta codificações aceitas e recomenda o Content-Encoding ideal a servir em milissegundos.
• Analisador de Accept-Encoding online seguro: os dados do cabeçalho nunca saem do seu dispositivo. O analisador roda inteiramente no seu navegador - sem envios a servidor, sem transmissão de dados, 100% privado. Seguro para analisar cabeçalhos de logs de tráfego de produção e APIs internas.
• Detecção completa de valores q e codificações: o analisador decodifica todas as codificações padrão - GZIP, Brotli (br), Zstandard (zstd), DEFLATE e identity - com barras de preferência de valores q, detalhes de compatibilidade de navegadores e um trecho de configuração Nginx pronto para usar.
• 100% grátis para sempre: o analisador de cabeçalho accept-encoding é totalmente grátis, sem cadastro, sem plano premium, sem limites e sem anúncios. Analise cabeçalhos Accept-Encoding ilimitados sem custo algum, para sempre.

Estes são os cenários mais comuns.

• Depurar a negociação de compressão HTTP: quando um servidor não serve respostas comprimidas, cole o cabeçalho Accept-Encoding da aba Rede das ferramentas de desenvolvedor do navegador no analisador para confirmar que o cliente realmente aceita GZIP ou Brotli - e verificar se o servidor está lendo o cabeçalho corretamente.
• Diagnosticar respostas de API ilegíveis: se um cliente de API recebe dados binários ilegíveis em vez de JSON, pode estar recebendo uma resposta comprimida que não consegue descomprimir. Use o analisador para verificar se o cabeçalho Accept-Encoding do cliente inclui a codificação que o servidor está enviando.
• Validar a configuração do servidor: antes de implantar uma nova configuração de compressão no Nginx ou Apache, use o analisador para verificar se seus clientes-alvo (navegadores, apps móveis, consumidores de API) realmente aceitam a codificação que você planeja servir - e receba um trecho de configuração pronto para usar.
• Auditar a compressão de clientes de API: audite os cabeçalhos Accept-Encoding enviados pelos seus clientes de API - apps móveis, SDKs e integrações de terceiros. O analisador mostra exatamente quais codificações cada cliente aceita, ajudando você a decidir se ativa Brotli ou Zstandard nos seus endpoints.
• Verificar compressão em CDN e proxy: CDNs e proxies reversos às vezes removem ou modificam os cabeçalhos Accept-Encoding antes de encaminhar as requisições aos servidores de origem. Use o analisador para comparar cabeçalhos em diferentes pontos do seu pipeline de requisições e identificar onde a negociação de compressão falha.
• Pesquisa de compatibilidade de navegadores: pesquise quais algoritmos de compressão diferentes navegadores e clientes HTTP aceitam analisando seus cabeçalhos Accept-Encoding. O analisador mostra percentuais de suporte por navegador para cada codificação, ajudando você a decidir quais algoritmos priorizar.

O cabeçalho de requisição HTTP Accept-Encoding é enviado por clientes (navegadores, curl, clientes de API, apps móveis) para informar ao servidor quais algoritmos de compressão de conteúdo eles conseguem descomprimir. O servidor lê esse cabeçalho e escolhe o melhor Content-Encoding para a resposta - normalmente Brotli para navegadores modernos ou GZIP como alternativa universal. Nosso analisador de cabeçalho accept-encoding lê esse cabeçalho, decodifica cada token de codificação e sua preferência q, e diz exatamente qual codificação servir para obter a máxima eficiência de compressão.

São três etapas.

1. 1 Cole seu cabeçalho Accept-Encoding: copie o cabeçalho das ferramentas de desenvolvedor do navegador (aba Rede → cabeçalhos de requisição), de uma saída de curl -v ou dos logs de acesso do seu servidor. Você pode colar a linha completa (incluindo o nome do cabeçalho) ou apenas o valor. O analisador remove o nome do cabeçalho automaticamente.
2. 2 Clique em «Analisar cabeçalho»: o analisador divide o valor do cabeçalho por vírgulas, processa cada token de codificação e seu parâmetro q opcional, e consulta a compatibilidade de navegadores e recomendações de cada codificação. Todo o processamento roda no seu navegador - nenhum dado é enviado a servidor.
3. 3 Leia os resultados e configure seu servidor: o analisador mostra um resumo de suporte, a codificação preferida a servir, um detalhamento de cada token com barras de valores q e um trecho de configuração Nginx pronto para usar com a combinação de codificações detectada.

Veja o que o analisador extrai do cabeçalho.

• Tokens de codificação: cada codificação separada por vírgula no valor do cabeçalho é processada individualmente - gzip, br, zstd, deflate, identity e o curinga (*) são todos reconhecidos e decodificados com descrições e dados de suporte de navegadores.
• Valores q: o parâmetro q= opcional em cada token indica a preferência do cliente (0,0 = recusada, 1,0 = preferida). O analisador ordena os tokens por valor q e visualiza a preferência com um gráfico de barras.
• Codificação preferida: o analisador determina a melhor codificação única a servir com base nas codificações aceitas pelo cliente - priorizando Brotli sobre Zstandard, sobre GZIP e sobre DEFLATE.
• Trecho de configuração do servidor: um trecho de configuração Nginx pronto para usar é gerado para a combinação de codificações detectada - alternativa Brotli + GZIP, alternativa Zstandard + GZIP ou apenas GZIP.

A negociação de conteúdo HTTP é o mecanismo pelo qual clientes e servidores concordam com a melhor representação de um recurso. O cabeçalho Accept-Encoding é o lado do cliente na negociação de compressão - ele lista o que o cliente consegue processar. O servidor responde com um cabeçalho Content-Encoding indicando qual codificação realmente usou. Sempre inclua um cabeçalho de resposta Vary: Accept-Encoding ao servir conteúdo comprimido - isso diz às CDNs e aos proxies de cache para armazenar versões em cache separadas para respostas comprimidas e não comprimidas, evitando saída ilegível para clientes que não aceitam compressão.