Saltar al contenido

Referencia de códigos de estado HTTP

Los códigos de estado HTTP que realmente aparecen en el desarrollo web, organizados por clase: para diseñar APIs, depurar y gestionar errores.

Qué es un código de estado HTTP

Un código de estado HTTP es el número de tres cifras con el que el servidor describe el resultado de una petición del cliente (un navegador o un cliente de API). El primer dígito fija la categoría, dando cinco clases de 1xx a 5xx. Devolver el código correcto es fundamental al diseñar una API RESTful.

1xx 2xx 3xx 4xx 5xx 1xx Informational (100, 101, 103) 2xx Success (200, 201, 204) 3xx Redirection (301, 302, 304) 4xx Client Error (400, 404, 422) 5xx Server Error (500, 502, 503)
Diagrama: clasificación de códigos de estado HTTP (5 clases)

1xx — Informativas

La petición se recibió y el procesamiento continúa. Los navegadores las gestionan automáticamente, así que rara vez se tratan a mano.

CódigoNombreSignificado
100ContinueSe recibió la primera parte de la petición; el cliente puede continuar
101Switching ProtocolsCambio de protocolo aceptado; se usa al establecer una conexión WebSocket
103Early HintsUna pista para que el cliente empiece a precargar recursos antes de la respuesta final

2xx — Éxito

La petición se aceptó y se procesó. Es la clase que más se usa al desarrollar APIs.

CódigoNombreSignificadoUso habitual
200OKPetición correctaGET, PUT o PATCH correctos
201CreatedPetición correcta y se creó un recurso nuevoUn POST que creó un recurso
202AcceptedPetición aceptada pero aún sin procesarAl aceptar un trabajo asíncrono
204No ContentPetición correcta sin contenido que devolverUn DELETE correcto, o un PUT que solo actualiza
206Partial ContentRespuesta parcial a una petición de rangoAl reanudar la descarga de un archivo grande

3xx — Redirección

Hace falta una acción adicional para completar la petición, normalmente seguir una redirección. Son clave para el SEO y las migraciones de URL.

CódigoNombreSignificadoUso habitual
301Moved PermanentlyEl recurso se movió de forma permanenteCambios de URL y migraciones de dominio; transmite las señales SEO
302FoundRedirigido temporalmente a otra URLUn traslado temporal durante el mantenimiento
303See OtherConsultar otra URL con GETRedirección tras un POST (patrón PRG)
304Not ModifiedEl recurso no ha cambiadoUsa la caché del navegador y ahorra ancho de banda
307Temporary RedirectRedirección temporal que conserva el métodoUn traslado temporal de HTTP a HTTPS
308Permanent RedirectRedirección permanente que conserva el métodoTraslado permanente de un endpoint de API

4xx — Error del cliente

El problema está en el cliente, normalmente el contenido de la petición o las credenciales.

CódigoNombreSignificadoUso habitual
400Bad RequestLa sintaxis de la petición no es válidaErrores de validación, JSON mal formado
401UnauthorizedSe requiere autenticaciónSin sesión iniciada o token caducado
403ForbiddenSin permiso de accesoAutenticado pero sin acceso al recurso
404Not FoundNo se encontró el recursoUna URL inexistente o un recurso eliminado
405Method Not AllowedMétodo HTTP no permitidoEnviar POST a un endpoint solo de GET
408Request TimeoutLa petición agotó el tiempo de esperaCuando el cliente envía los datos demasiado despacio
409ConflictConflicto de recursosRegistros duplicados, colisiones de bloqueo optimista
413Payload Too LargeEl cuerpo de la petición es demasiado grandeSe superó el límite de subida
415Unsupported Media TypeTipo de medio no admitidoUn Content-Type incorrecto
422Unprocessable EntitySintaxis correcta pero imposible de procesar semánticamenteErrores de validación (detallados)
429Too Many RequestsSe superó el límite de peticionesCuotas de llamadas a la API

5xx — Error del servidor

El procesamiento falló en el servidor, normalmente por un error de configuración o un fallo de la aplicación.

CódigoNombreSignificadoUso habitual
500Internal Server ErrorError interno del servidorExcepciones no capturadas, fallos de la aplicación
501Not ImplementedEl servidor no admite la funcionalidadUn endpoint de API aún sin implementar
502Bad GatewayLa pasarela recibió una respuesta no válidaEl servidor upstream tras el proxy inverso no responde
503Service UnavailableServicio no disponibleEn mantenimiento o sobrecargado
504Gateway TimeoutTiempo de espera de la pasarela agotadoEl servidor upstream no respondió a tiempo

Preguntas frecuentes

¿Cuál es la diferencia entre 401 y 403?

401 Unauthorized indica que hace falta autenticarse e invita a iniciar sesión o presentar un token. 403 Forbidden indica que el cliente está autenticado pero no tiene permiso sobre el recurso. Un usuario normal que entra en una página solo de administradores debe recibir un 403.

¿Cuál es la diferencia entre 301 y 308?

Ambas son redirecciones permanentes, pero con 301 el método HTTP puede reescribirse a GET por el camino. 308 reenvía la petición conservando el método. Usa 308 cuando un POST deba seguir siendo POST en el destino.

¿Qué hago ante un error 413?

Cuando una subida devuelve 413 Payload Too Large, revisa los límites de cada capa: el servidor web (client_max_body_size en Nginx, LimitRequestBody en Apache) y PHP (upload_max_filesize, post_max_size). Los archivos de prueba de umbral de DevLab permiten confirmar el límite real.

❓ Preguntas frecuentes

¿Qué códigos de estado afectan al SEO?
301 y 308 transfieren las señales; 302 y 307 se tratan como temporales y se conserva la URL original. Tanto 404 como 410 sacan la página del índice, pero 410 detiene antes el rastreo repetido. 503 se lee como una caída temporal, y añadir Retry-After permite regular la frecuencia de rastreo. Devolver 200 para una página que no existe se trata como soft 404 y penaliza la calidad.
¿Un 4xx es culpa mía o del servidor?
Un 4xx señala a la petición, y repetirla igual no cambiará el resultado. Un 5xx señala al servidor y puede funcionar más tarde. La distinción marca directamente el diseño de reintentos: ante un 4xx, ríndete y registra; ante un 5xx, reintenta con retroceso exponencial. La excepción es el 429, que es 4xx pero debe reintentarse según Retry-After.
¿Puedo definir mis propios códigos de estado?
No lo hagas. Los proxies intermedios, las CDN y los clientes HTTP están especificados para tratar un código desconocido como el x00 de su clase, así que un 499 se maneja igual que un 400. El código propio no sobrevive al trayecto y además pierdes el detalle. Elige el código estándar que encaje y pon los detalles en el cuerpo de la respuesta; Problem Details de RFC 9457 es lo habitual.