Referência de códigos de status HTTP

Pesquise e filtre 46 códigos de status HTTP com resumo de uma linha e notas práticas de correção para cada um.

Esta referência é estática e totalmente local. Suas buscas nunca saem da página.

—

Como funciona

Toda resposta HTTP começa com um código de três dígitos, e só o primeiro já diz em qual das cinco classes você está. Esta referência cobre os 46 códigos que um desenvolvedor realmente encontra, cada um com um resumo de uma linha e uma nota expandida com a causa comum e a primeira ação a tentar — filtre por classe, busque por código ou frase e clique em qualquer linha para abrir.

As cinco classes
1xx é informativo — sinais intermediários que normalmente se completam no manejo de conexão do cliente. 2xx é sucesso, com subtipos para criado (201), aceito-mas-inacabado (202) e deliberadamente vazio (204). 3xx é redirecionamento: vá para outra URL sob regras declaradas. 4xx é erro do cliente — o pedido enviado não era aceitável. 5xx é erro do servidor — o pedido estava bom, o servidor não entregou. A divisão mais útil ao depurar: 4xx olhe o que você enviou, 5xx olhe o que eles rodam.
Idempotência e novas tentativas
Seguros para repetir com backoff: 408, 425, 429 (respeite Retry-After) e a família 5xx — 500, 502, 503, 504. Nunca valem retry às cegas os 4xx sobre o próprio payload (400, 413, 415) nem falhas de autorização (401, 403). Códigos como 409 e 412 só aceitam nova tentativa depois de você reler o estado atual e resolver o conflito — repetir o mesmo pedido só falha de novo.
Redirecionamentos permanentes vs temporários
301 e 308 ficam em cache praticamente para sempre: use só quando a URL antiga nunca voltará, e saiba que um erro continua perseguindo usuários depois de corrigido o servidor. 302, 303 e 307 não são armazenados — o navegador pergunta de novo pela URL original — e diferem no modo de reescrever o método: 303 força GET, 307 preserva o método, 302 o conserva na prática mas sem garantia.

Perguntas frequentes

Qual a diferença entre 429 e 503?

A culpa e a recuperação. 429 Too Many Requests significa que seu cliente estourou um limite de requisições — o pedido era bem-formado e o servidor estava saudável, mas você perguntou demais, então recue e respeite o Retry-After. 503 Service Unavailable significa que o próprio servidor está sobrecarregado ou em manutenção: qualquer pedido receberia a mesma resposta, então é problema de capacidade, não do seu comportamento. Os dois convidam a repetir com backoff; só o 429 piora especificamente para você.

Como o navegador usa o 304?

Através de requisições condicionais. Quando uma cópia em cache envelhece, o navegador revalida enviando If-None-Match (com o ETag guardado) ou If-Modified-Since; se nada mudou, o servidor responde 304 Not Modified sem corpo e o navegador serve a cópia local. Você vê isso no DevTools como uma resposta minúscula, e não é erro — se parece que 'suas mudanças não aparecem', o que inspecionar são os cabeçalhos de cache, não o 304 em si.

O 418 I'm a Teapot é um padrão de verdade?

Sim, no sentido RFC: vem da RFC 2324, a especificação April Fools de 1998 do HTCPCP, o Hyper Text Coffee Pot Control Protocol. As especificações HTTP modernas (RFC 9110 e RFC 9562) reservam explicitamente o código para que bules antigos continuem funcionando. Na prática, um 418 de verdade hoje costuma ser piada ou honeypot deliberado de sistemas anti-bot.

Por que apenas 46 códigos?

Porque o HTTP define mais de sessenta códigos e a maioria nunca encontra o resto. Esta lista cobre todos os da semântica HTTP central (RFC 9110/9111) mais os acrescentos das RFC 6585, 4918/5842 (WebDAV), 7725, 8470 e o 425 relacionado a TLS — os códigos que você pode realisticamente ver no console do navegador, num log de servidor ou na traca de um proxy, em um só lugar pesquisável.

Algo é enviado para um servidor?

Não. As 46 entradas estão embutidas na própria página; buscar e filtrar acontece no JavaScript da sua aba. Suas consultas nunca saem do dispositivo e a página funciona sem nenhuma rede depois de carregada.