Continue
El servidor recibió las cabeceras y el cliente puede enviar el cuerpo. Se usa con "Expect: 100-continue" antes de subidas grandes.
RFC 9110Códigos de estado HTTP
Busca por número o nombre, o filtra por clase. Cada código enlaza a su especificación.
1xx Informativos
La petición se recibió y el proceso continúa. Raro en el código de una aplicación.
Switching Protocols
El servidor acepta cambiar de protocolo como pidió el cliente, por ejemplo de HTTP/1.1 a WebSocket.
RFC 9110Processing
WebDAV: el servidor aceptó la petición y sigue procesándola, así que el cliente no debe cortar por tiempo.
RFC 2518Early Hints
Envía pronto cabeceras Link para que el navegador precargue CSS o fuentes mientras el servidor prepara la respuesta final.
RFC 82972xx Éxito
La petición se recibió, se entendió y se aceptó.
Created
Se creó un recurso nuevo, normalmente tras un POST. La cabecera Location debería apuntar a él.
RFC 9110Accepted
La petición se aceptó para procesarla pero aún no ha terminado, por ejemplo una tarea en segundo plano en cola.
RFC 9110Non-Authoritative Information
Respuesta correcta pero modificada por un proxy de transformación, así que no es exactamente lo que envió el origen.
RFC 9110No Content
Éxito sin cuerpo que devolver. Habitual en DELETE o al guardar un formulario sin recargar la página.
RFC 9110Reset Content
Éxito; el cliente debe reiniciar el formulario o la vista que envió la petición.
RFC 9110Partial Content
Solo se devuelve una parte del recurso, según la cabecera Range. Se usa para reanudar descargas y avanzar en vídeos.
RFC 91103xx Redirección
Hace falta otra acción, normalmente seguir otra URL, para completar la petición.
Multiple Choices
Existen varias representaciones (por ejemplo idiomas o formatos) y el cliente debe elegir una.
RFC 9110Moved Permanently
El recurso tiene una nueva URL permanente, indicada en Location. Los buscadores transfieren el posicionamiento.
RFC 9110Found
El recurso está temporalmente en otra URL. Los clientes siguen usando la original; los navegadores pueden convertir un POST en GET.
RFC 9110See Other
El resultado está en otra URL y se obtiene con GET. Se usa tras un POST de formulario para evitar reenvíos (Post/Redirect/Get).
RFC 9110Not Modified
La copia en caché sigue siendo válida (coincidió If-None-Match o If-Modified-Since), así que no se envía cuerpo.
RFC 9110Temporary Redirect
Redirección temporal que conserva el método y el cuerpo: un POST sigue siendo POST.
RFC 9110Permanent Redirect
Redirección permanente que conserva el método y el cuerpo. La versión estricta del 301.
RFC 91104xx Error del cliente
La petición es incorrecta: sintaxis errónea, falta autenticación, no hay permiso o el recurso no existe.
Bad Request
El servidor no puede procesar la petición porque está mal formada: sintaxis inválida, JSON roto o parámetros erróneos.
RFC 9110Unauthorized
Falta autenticación o no es válida. La respuesta incluye WWW-Authenticate con el método para iniciar sesión.
RFC 9110Payment Required
Reservado para futuros sistemas de pago digital; algunas API lo usan cuando hay que pagar una suscripción o cuota.
RFC 9110Forbidden
El servidor sabe quién eres pero rechaza la acción por falta de permisos. Volver a iniciar sesión no lo arregla.
RFC 9110Method Not Allowed
El método HTTP no se admite en esta URL, por ejemplo un POST a un recurso de solo lectura. Allow indica los métodos válidos.
RFC 9110Not Acceptable
El servidor no puede generar una respuesta que encaje con las cabeceras Accept (tipo, idioma o codificación).
RFC 9110Proxy Authentication Required
Como el 401, pero el cliente debe autenticarse antes con el proxy.
RFC 9110Request Timeout
El servidor esperó demasiado a que el cliente terminara de enviar la petición y cerró la conexión.
RFC 9110Conflict
La petición choca con el estado actual, como un conflicto de edición o una clave única duplicada.
RFC 9110Gone
El recurso se eliminó a propósito y no volverá. Los buscadores lo retiran antes que con un 404.
RFC 9110Precondition Failed
Una cabecera condicional como If-Match no coincidió; se usa a menudo para no sobrescribir cambios ajenos.
RFC 9110Content Too Large
El cuerpo de la petición supera el tamaño permitido (antes "Payload Too Large").
RFC 9110URI Too Long
La URL es más larga de lo que el servidor admite, a menudo por meter demasiados datos en la query de un GET.
RFC 9110Unsupported Media Type
El formato del cuerpo (Content-Type) no se admite, por ejemplo XML enviado a una API que solo acepta JSON.
RFC 9110I'm a teapot
Una broma del Día de los Inocentes del protocolo de control de cafeteras: una tetera no puede hacer café. Algunos sitios lo usan como huevo de Pascua.
RFC 2324Misdirected Request
La petición llegó a un servidor que no puede responder para este host, por ejemplo cuando una conexión HTTP/2 reutilizada apunta al origen equivocado.
RFC 9110Unprocessable Content
La sintaxis es correcta pero el contenido no es válido, por ejemplo falla la validación (antes "Unprocessable Entity").
RFC 9110Too Early
El servidor no procesará una petición que podría repetirse, como los datos tempranos de TLS 1.3.
RFC 8470Precondition Required
El servidor exige peticiones condicionales (If-Match) para evitar actualizaciones perdidas.
RFC 6585Too Many Requests
El cliente envió demasiadas peticiones en poco tiempo (límite de tasa). Retry-After indica cuándo reintentar.
RFC 6585Request Header Fields Too Large
Las cabeceras son demasiado grandes en total o una lo es, a menudo por cookies enormes.
RFC 6585Unavailable For Legal Reasons
El recurso está bloqueado por motivos legales, como censura u orden judicial. El número alude a "Fahrenheit 451".
RFC 77255xx Error del servidor
La petición parecía válida pero el servidor no pudo procesarla.
Internal Server Error
Error genérico: algo inesperado falló en el servidor. Revisa los registros del servidor.
RFC 9110Not Implemented
El servidor no admite la función o el método necesarios para atender la petición.
RFC 9110Bad Gateway
Un gateway o proxy recibió una respuesta no válida del servidor de origen, por ejemplo si la app detrás de Nginx se cayó.
RFC 9110Service Unavailable
El servidor no puede atender peticiones temporalmente por sobrecarga o mantenimiento. Retry-After puede indicar cuándo volver.
RFC 9110Variant Also Negotiates
Negociación de contenido mal configurada: la variante elegida intenta negociar a su vez.
RFC 2295Insufficient Storage
WebDAV: el servidor no puede almacenar los datos necesarios para completar la petición.
RFC 4918Network Authentication Required
El cliente debe iniciar sesión en la red primero, normalmente un portal cautivo de Wi-Fi de hotel o aeropuerto.
RFC 6585¿Qué son los códigos de estado HTTP?
Toda respuesta HTTP empieza con un código de tres dígitos que indica al cliente cómo fue la petición. El primer dígito marca la clase: 1xx informativos, 2xx éxito, 3xx redirección, 4xx errores del cliente y 5xx errores del servidor. Navegadores, buscadores, cachés, clientes de API y herramientas de monitorización actúan según estos códigos, así que elegir bien importa: un 301 transfiere el valor SEO a la nueva URL y un 302 no, un 503 pide a los rastreadores que vuelvan más tarde y un 429 pide a los clientes de API que bajen el ritmo. Los códigos se definen sobre todo en el RFC 9110 (HTTP Semantics), y algunos en RFC propios.
Funciones
- • Los 61 códigos registrados en la IANA, del 100 al 511
- • Explicación clara de qué significa cada código y cuándo usarlo
- • Búsqueda instantánea por número, nombre o palabra clave y filtros por clase
- • Enlaces directos a la sección del RFC que define cada código
- • Colores por clase y anclas #código para compartir enlaces
Rápido y sin conexión
Toda la referencia está dentro de la página, así que la búsqueda funciona al instante en tu navegador sin peticiones al servidor.
Referencia con búsqueda, sin rastreo.
Cómo usar: Códigos de estado HTTP
- 1
Escribe un número como 404, un nombre como "gateway" o una palabra como "redirect" en el buscador. Los resultados se actualizan al escribir.
- 2
Usa los botones de clase (1xx a 5xx) para acotar la lista, por ejemplo para repasar todos los errores del cliente a la vez.
- 3
Lee la explicación de cada código: qué significa, cuándo debe enviarlo un servidor y cómo reaccionan los clientes.
- 4
Sigue el enlace al RFC para la especificación exacta o comparte un código con un ancla como #429.
Ejemplos prácticos
Diseñar una API REST
Devuelve 201 Created con cabecera Location tras un POST, 204 No Content tras un DELETE, 400 si el JSON está mal formado, 422 para errores de validación y 409 si la petición choca con el estado actual.
Mover páginas sin perder SEO
Usa 301 o 308 para traslados permanentes, así los buscadores transfieren el posicionamiento, y 302 o 307 para redirecciones temporales como pruebas A/B. 308 y 307 además mantienen POST como POST.
Errores de autenticación
Envía 401 si el usuario no ha iniciado sesión o el token no es válido, y 403 si se sabe quién es pero no tiene permiso. Muchas API devuelven 404 en lugar de 403 para ocultar que el recurso existe.
Mantenimiento y sobrecarga
Devuelve 503 con la cabecera Retry-After durante el mantenimiento para que los rastreadores conserven tu posicionamiento, y 429 con Retry-After cuando un cliente supera su límite de peticiones.
Preguntas frecuentes
¿Qué diferencia hay entre 401 y 403?+
401 Unauthorized significa "¿quién eres?": falta autenticación o falló. 403 Forbidden significa "sé quién eres, pero no puedes hacer esto". Volver a iniciar sesión arregla un 401, no un 403.
¿301 o 302 para redirigir?+
Usa 301 (o 308) cuando la URL antigua desaparece para siempre y 302 (o 307) cuando volverá. Usar 302 para un traslado permanente puede retrasar la indexación de la nueva URL.
¿Qué diferencia hay entre 502, 503 y 504?+
502 Bad Gateway: un proxy recibió una respuesta no válida del servidor de origen. 503 Service Unavailable: el servidor está sobrecargado o en mantenimiento. 504 Gateway Timeout: el origen no respondió a tiempo.
¿Pueden los errores devolver 200 con un mensaje?+
No. Clientes, cachés y monitorización se basan en el código de estado. Devolver 200 en fallos oculta los errores a las herramientas y puede hacer que se indexen páginas de error como "soft 404".