Continue
O servidor recebeu os cabeçalhos e o cliente pode enviar o corpo. Usado com "Expect: 100-continue" antes de uploads grandes.
RFC 9110Códigos de status HTTP
Pesquise por número ou nome, ou filtre por classe. Cada código leva à sua especificação.
1xx Informativos
A requisição foi recebida e o processo continua. Raro no código de aplicações.
Switching Protocols
O servidor aceita trocar de protocolo como o cliente pediu, por exemplo de HTTP/1.1 para WebSocket.
RFC 9110Processing
WebDAV: o servidor aceitou a requisição e ainda está processando, então o cliente não deve encerrar por tempo.
RFC 2518Early Hints
Envia cabeçalhos Link cedo para o navegador pré-carregar CSS ou fontes enquanto o servidor prepara a resposta final.
RFC 82972xx Sucesso
A requisição foi recebida, entendida e aceita.
Created
Um novo recurso foi criado, normalmente após um POST. O cabeçalho Location deve apontar para ele.
RFC 9110Accepted
A requisição foi aceita para processamento mas ainda não terminou, por exemplo um job em fila.
RFC 9110Non-Authoritative Information
Resposta OK, mas modificada por um proxy de transformação, então não é exatamente o que a origem enviou.
RFC 9110No Content
Sucesso sem corpo para retornar. Comum em DELETE ou ao salvar um formulário sem recarregar a página.
RFC 9110Partial Content
Só parte do recurso é retornada, conforme o cabeçalho Range. Usado em downloads retomáveis e para avançar vídeos.
RFC 91103xx Redirecionamento
É preciso outra ação, geralmente seguir outra URL, para concluir a requisição.
Multiple Choices
Existem várias representações (por exemplo idiomas ou formatos) e o cliente deve escolher uma.
RFC 9110Moved Permanently
O recurso tem uma nova URL permanente, indicada em Location. Os buscadores transferem o ranqueamento.
RFC 9110Found
O recurso está temporariamente em outra URL. Os clientes continuam usando a original; navegadores podem trocar POST por GET.
RFC 9110See Other
O resultado está em outra URL, obtida com GET. Usado após um POST de formulário para evitar reenvio (Post/Redirect/Get).
RFC 9110Not Modified
A cópia em cache ainda é válida (If-None-Match ou If-Modified-Since bateu), então nenhum corpo é enviado.
RFC 9110Temporary Redirect
Redirecionamento temporário que mantém o método e o corpo: um POST continua POST.
RFC 9110Permanent Redirect
Redirecionamento permanente que mantém o método e o corpo. A versão estrita do 301.
RFC 91104xx Erro do cliente
A requisição está errada: sintaxe inválida, falta de autenticação, sem permissão ou recurso inexistente.
Bad Request
O servidor não consegue processar a requisição malformada: sintaxe inválida, JSON quebrado ou parâmetros errados.
RFC 9110Unauthorized
A autenticação está ausente ou inválida. A resposta traz WWW-Authenticate dizendo como fazer login.
RFC 9110Payment Required
Reservado para futuros sistemas de pagamento digital; algumas APIs usam quando uma assinatura ou cota precisa ser paga.
RFC 9110Forbidden
O servidor sabe quem você é, mas recusa a ação por falta de permissão. Logar de novo não resolve.
RFC 9110Method Not Allowed
O método HTTP não é suportado nesta URL, por exemplo POST num recurso somente leitura. Allow lista os métodos válidos.
RFC 9110Not Acceptable
O servidor não consegue gerar uma resposta compatível com os cabeçalhos Accept (tipo, idioma ou codificação).
RFC 9110Proxy Authentication Required
Como o 401, mas o cliente precisa se autenticar primeiro no proxy.
RFC 9110Request Timeout
O servidor esperou demais o cliente terminar de enviar a requisição e fechou a conexão.
RFC 9110Conflict
A requisição conflita com o estado atual, como um conflito de edição ou chave única duplicada.
RFC 9110Gone
O recurso foi removido de propósito e não vai voltar. Os buscadores o retiram mais rápido que um 404.
RFC 9110Precondition Failed
Um cabeçalho condicional como If-Match não bateu; usado para não sobrescrever alterações de outra pessoa.
RFC 9110Content Too Large
O corpo da requisição é maior do que o servidor permite (antes "Payload Too Large").
RFC 9110URI Too Long
A URL é maior do que o servidor aceita, geralmente por colocar dados demais na query string de um GET.
RFC 9110Unsupported Media Type
O formato do corpo (Content-Type) não é suportado, por exemplo XML enviado a uma API só de JSON.
RFC 9110I'm a teapot
Uma piada de 1º de abril do protocolo de controle de cafeteiras: um bule de chá não faz café. Alguns sites usam como easter egg.
RFC 2324Misdirected Request
A requisição chegou a um servidor que não pode responder por este host, por exemplo quando uma conexão HTTP/2 reaproveitada aponta para a origem errada.
RFC 9110Unprocessable Content
A sintaxe está certa mas o conteúdo é inválido, por exemplo falha nas regras de validação (antes "Unprocessable Entity").
RFC 9110Too Early
O servidor não processa uma requisição que pode ser repetida, como os early data do TLS 1.3.
RFC 8470Upgrade Required
O cliente precisa trocar para outro protocolo, indicado no cabeçalho Upgrade.
RFC 9110Precondition Required
O servidor exige requisições condicionais (If-Match) para evitar atualizações perdidas.
RFC 6585Too Many Requests
O cliente enviou requisições demais em pouco tempo (limite de taxa). Retry-After diz quando tentar de novo.
RFC 6585Request Header Fields Too Large
Os cabeçalhos são grandes demais no total ou um deles é, muitas vezes por cookies enormes.
RFC 6585Unavailable For Legal Reasons
O recurso está bloqueado por motivos legais, como censura ou ordem judicial. O número faz referência a "Fahrenheit 451".
RFC 77255xx Erro do servidor
A requisição parecia válida, mas o servidor não conseguiu processá-la.
Internal Server Error
Erro genérico: algo inesperado deu errado no servidor. Verifique os logs do servidor.
RFC 9110Not Implemented
O servidor não suporta o recurso ou o método necessário para atender a requisição.
RFC 9110Bad Gateway
Um gateway ou proxy recebeu uma resposta inválida do servidor de origem, por exemplo quando a aplicação atrás do Nginx caiu.
RFC 9110Service Unavailable
O servidor não pode atender requisições no momento por sobrecarga ou manutenção. Retry-After pode indicar quando voltar.
RFC 9110Variant Also Negotiates
Negociação de conteúdo mal configurada: a variante escolhida tenta negociar de novo.
RFC 2295Insufficient Storage
WebDAV: o servidor não consegue armazenar os dados necessários para concluir a requisição.
RFC 4918Network Authentication Required
O cliente precisa fazer login na rede primeiro, geralmente um portal cativo de Wi-Fi de hotel ou aeroporto.
RFC 6585O que são códigos de status HTTP?
Toda resposta HTTP começa com um código de três dígitos que informa ao cliente como foi a requisição. O primeiro dígito define a classe: 1xx informativos, 2xx sucesso, 3xx redirecionamento, 4xx erros do cliente e 5xx erros do servidor. Navegadores, buscadores, caches, clientes de API e ferramentas de monitoramento agem com base nesses códigos, então escolher o certo importa: um 301 passa o valor de SEO para a nova URL e um 302 não, um 503 pede aos robôs que voltem depois e um 429 pede aos clientes de API que desacelerem. Os códigos são definidos principalmente na RFC 9110 (HTTP Semantics), e alguns em RFCs próprias.
Recursos
- • Todos os 61 códigos registrados na IANA, de 100 a 511
- • Explicação simples do que cada código significa e quando usar
- • Busca instantânea por número, nome ou palavra-chave e filtros por classe
- • Links diretos para a seção da RFC que define cada código
- • Cores por classe e âncoras #código para compartilhar links
Rápido e offline
Toda a referência está na página, então a busca funciona na hora no navegador, sem requisições ao servidor.
Referência pesquisável, sem rastreamento.
Como usar: Códigos de status HTTP
- 1
Digite um número como 404, um nome como "gateway" ou uma palavra como "redirect" na busca. Os resultados mudam enquanto você digita.
- 2
Use os botões de classe (1xx a 5xx) para filtrar a lista, por exemplo para revisar todos os erros do cliente de uma vez.
- 3
Leia a explicação de cada código: o que significa, quando o servidor deve enviá-lo e como os clientes reagem.
- 4
Siga o link da RFC para a especificação exata ou compartilhe um código com uma âncora como #429.
Exemplos práticos
Projetar uma API REST
Retorne 201 Created com cabeçalho Location após um POST, 204 No Content após um DELETE, 400 para JSON malformado, 422 para erros de validação e 409 quando a requisição conflita com o estado atual.
Mudar páginas sem perder SEO
Use 301 ou 308 para mudanças permanentes, assim os buscadores transferem o ranqueamento, e 302 ou 307 para redirecionamentos temporários como testes A/B. 308 e 307 também mantêm POST como POST.
Erros de autenticação
Envie 401 quando o usuário não está logado ou o token é inválido, e 403 quando o usuário é conhecido mas não tem permissão. Muitas APIs retornam 404 em vez de 403 para esconder que o recurso existe.
Manutenção e sobrecarga
Retorne 503 com o cabeçalho Retry-After durante a manutenção para os robôs manterem seu ranqueamento, e 429 com Retry-After quando um cliente passa do limite de requisições.
Perguntas frequentes
Qual a diferença entre 401 e 403?+
401 Unauthorized quer dizer "quem é você?": falta autenticação ou ela falhou. 403 Forbidden quer dizer "sei quem você é, mas você não pode fazer isso". Logar de novo resolve um 401, não um 403.
301 ou 302 para redirecionar?+
Use 301 (ou 308) quando a URL antiga sumiu de vez e 302 (ou 307) quando ela vai voltar. Usar 302 para uma mudança permanente pode atrasar a indexação da nova URL.
Qual a diferença entre 502, 503 e 504?+
502 Bad Gateway: um proxy recebeu uma resposta inválida do servidor de origem. 503 Service Unavailable: o servidor está sobrecarregado ou em manutenção. 504 Gateway Timeout: a origem não respondeu a tempo.
Erros podem retornar 200 com mensagem?+
Não. Clientes, caches e monitoramento dependem do código de status. Retornar 200 em falhas esconde erros das ferramentas e pode fazer páginas de erro serem indexadas como "soft 404".