Referência completa de códigos de status HTTP: significado, causas, RFC e como tratar, tudo no navegador.
Os códigos de status HTTP comunicam, em três dígitos, o resultado de cada requisição entre cliente e servidor, e são definidos principalmente pela RFC 9110. O primeiro dígito define a família: 1xx (informativo, resposta provisória), 2xx (sucesso), 3xx (redirecionamento), 4xx (erro do cliente, como pedido malformado ou sem permissão) e 5xx (erro do servidor). Esta referência reúne os códigos das cinco famílias com o significado, a especificação (RFC) que o define, se a resposta é cacheável por padrão, se costuma ter corpo, além de causas comuns e formas de tratar os erros mais frequentes. É uma consulta totalmente offline: você digita o número (como 404) ou um termo (como timeout ou redirect) e vê a explicação na hora, sem que a ferramenta faça qualquer requisição de rede. Serve para depurar respostas de API, entender logs de servidor, escolher o código certo ao construir um endpoint e revisar redirecionamentos de SEO.
Todo código de status tem três dígitos, e o primeiro deles resume a natureza da resposta antes mesmo de você olhar o número exato. Saber ler a família é o atalho mais rápido para diagnosticar: um 4xx aponta o dedo para o cliente (a requisição), enquanto um 5xx aponta para o servidor (a infraestrutura). Isso muda completamente quem precisa agir, o desenvolvedor que fez a chamada ou quem opera o backend.
As faixas seguem a RFC 9110: 1xx é uma resposta provisória (o pedido chegou e o processamento continua), 2xx confirma sucesso, 3xx indica que falta uma ação extra (normalmente seguir um redirecionamento), 4xx sinaliza um erro do lado do cliente e 5xx um erro do lado do servidor.
Exemplo 1, 401 versus 403. Um 401 (Unauthorized) diz "eu não sei quem você é": faltam credenciais válidas, e enviar um token correto resolve. Um 403 (Forbidden) diz "eu sei quem você é, mas você não pode": a autenticação está ok, mas a permissão não existe, e reautenticar não muda nada. Confundir os dois leva a mandar o usuário para uma tela de login que nunca vai destravar o acesso.
Exemplo 2, redirecionamentos 301, 302 e 307/308. O 301 (Moved Permanently) é definitivo e consolida sinais de SEO no novo endereço; o 302 é temporário. Um detalhe crítico: 301 e 302 podem fazer o navegador trocar um POST por GET ao redirecionar, enquanto 307 e 308 preservam o método e o corpo originais, por isso APIs que redirecionam requisições POST devem usar 307/308 para não perder os dados enviados.
A referência é útil ao depurar uma API que devolve um código inesperado, ao ler logs de acesso (onde o status aparece em cada linha), ao decidir qual código retornar em um endpoint que você está construindo e ao auditar redirecionamentos para SEO. Para cada código curado, você vê a família, a RFC de origem, se ele é cacheável por padrão e se costuma trazer corpo.
O limite importante é de propósito: esta é uma consulta puramente local. A ferramenta não busca a URL que você digitar, não faz nenhuma requisição de rede e não acessa sites, ela apenas explica o significado dos códigos. Isso mantém a consulta rápida, privada e imune a bloqueios de firewall ou CORS.
Cole o código no seu HTML e a ferramenta aparece na sua página, sem a navegação e sem os anúncios do J-Kit. Ela continua rodando no navegador de quem visita o seu site.
<iframe
src="https://jkit.tools/embed/pt-BR/status-http"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="Status HTTP"
></iframe>Estas referências ajudam a contextualizar fórmulas, padrões, APIs e limitações usadas nesta página. Elas não substituem validação profissional quando o resultado tiver impacto jurídico, financeiro, médico ou operacional.
401 (Unauthorized) significa que falta autenticação válida, você precisa se identificar, e enviar credenciais corretas resolve. 403 (Forbidden) significa que você está autenticado, mas não tem permissão para o recurso; reautenticar não adianta. Na prática, 401 pede login e 403 indica falta de autorização, mesmo já logado.
O cliente deve continuar enviando o corpo da requisição (após um Expect: 100-continue).
O servidor concorda em trocar de protocolo (ex.: upgrade para WebSocket).
Permite pré-carregar recursos (Link headers) antes da resposta final.
Sucesso padrão. O corpo depende do método (GET retorna o recurso).
Recurso criado com sucesso; normalmente vem com header Location.
Pedido aceito para processamento assíncrono; ainda não concluído.
Sucesso, mas um proxy intermediário modificou o conteúdo da resposta original do servidor de origem.
Sucesso sem corpo de resposta (comum em DELETE e PUT).
Sucesso sem corpo; instrui o user agent a limpar o formulário ou a view que originou o pedido.
Resposta parcial a uma requisição com header Range (downloads, vídeo).
O recurso tem mais de uma representação; o cliente deveria escolher uma. Raramente usado na prática, sem um formato padronizado de escolha automática.
O recurso mudou de URL permanentemente; atualize links e favoritos.
Redirecionamento temporário; o método pode mudar para GET na prática.
Veja outro recurso com GET (padrão Post/Redirect/Get).
O recurso em cache ainda é válido (ETag/If-Modified-Since); use o cache. A resposta em si não carrega conteúdo, então a RFC 9110 não a lista como cacheável por padrão como o 200.
Redirecionamento temporário que preserva o método e o corpo.
Redirecionamento permanente que preserva o método e o corpo.
O servidor não entendeu o pedido por erro de sintaxe ou dados inválidos.
Falta autenticação válida. Apesar do nome, é sobre autenticação, não permissão.
Reservado para uso futuro pela RFC 9110. Algumas APIs de pagamento o reutilizam de forma não padronizada para sinalizar cobrança pendente.
Autenticado, mas sem permissão para o recurso. Reautenticar não resolve.
O recurso não existe nessa URL (ou o servidor não quer revelar que existe).
O método HTTP não é permitido nesse recurso (veja o header Allow).
Nenhuma representação atende ao Accept enviado pelo cliente.
Como o 401, mas a autenticação exigida é a de um proxy, não a do servidor de origem.
O cliente demorou demais para enviar o pedido completo.
Conflito com o estado atual do recurso (ex.: edição concorrente).
O recurso existia e foi removido permanentemente.
O servidor recusa o pedido sem um Content-Length definido.
Uma pré-condição enviada pelo cliente (If-Match, If-Unmodified-Since etc.) foi avaliada como falsa no servidor.
O corpo da requisição é maior do que o servidor aceita.
A URL é longa demais (geralmente query string gigante em GET).
O Content-Type do corpo não é suportado pelo endpoint.
O intervalo pedido no header Range não pôde ser atendido (comum em downloads retomados e streaming de vídeo).
Um servidor no caminho não conseguiu atender à expectativa do header Expect (ex.: 100-continue).
Piada de 1998 (RFC 2324/7168, protocolo HTCPCP). A RFC 9110 marca oficialmente o código como reservado (“Unused”) por causa do uso disseminado como piada, ele não pode ganhar um significado sério; ainda assim, segue amplamente implementado como easter egg em frameworks e ferramentas.
O pedido chegou a um servidor que não pode dar uma resposta autoritativa para essa origem, comum quando uma conexão HTTP/2 é reaproveitada entre domínios diferentes.
Sintaxe ok, mas a semântica é inválida (falha de validação de regras).
O recurso está bloqueado (extensão WebDAV), comum em serviços de armazenamento e edição colaborativa de arquivos.
O pedido falhou porque outro pedido do qual ele dependia falhou antes (extensão WebDAV).
O servidor recusa processar dados enviados cedo demais (anti-replay 0-RTT).
O cliente precisa trocar para outro protocolo (ex.: TLS mais novo).
O servidor exige uma pré-condição (ex.: If-Match) para evitar lost updates.
Rate limit atingido. Veja o header Retry-After para esperar.
Os headers (ou um cookie) são grandes demais.
Conteúdo bloqueado por motivos legais (censura, DMCA, GDPR).
Erro genérico e inesperado no servidor. Veja os logs do backend.
O servidor não suporta a funcionalidade necessária (ex.: método).
Um proxy/gateway recebeu uma resposta inválida do servidor upstream.
Servidor temporariamente indisponível (sobrecarga ou manutenção).
Um proxy/gateway não recebeu resposta do upstream a tempo.
A versão de HTTP do pedido não é suportada pelo servidor.
Erro de configuração da negociação de conteúdo: a variante escolhida também negocia, criando um laço que o servidor precisa cortar.
O servidor não tem espaço de armazenamento para concluir o pedido (WebDAV).
O servidor detectou um laço infinito ao processar um pedido WebDAV com profundidade ilimitada (Depth: infinity).
É preciso autenticar na rede (portais cativos de Wi-Fi).
Esta é uma referência offline: nada é enviado para a rede. A ferramenta não acessa nenhum site nem faz requisições, apenas explica os códigos.