La Guía Definitiva de los Códigos de Estado HTTP
Los códigos de estado HTTP indican el resultado del procesamiento de una solicitud por parte del servidor web. Se agrupan en cinco clases, cada una representando una categoría diferente de respuesta. Entender estos códigos es esencial para desarrolladores web, diseñadores de APIs, administradores de sistemas y cualquier persona que trabaje con tecnologías web. Los códigos de estado permiten a los clientes — ya sean navegadores, aplicaciones móviles u otros servidores — entender qué sucedió con su solicitud y cómo proceder.
Cómo Funcionan los Códigos de Estado HTTP
Cuando un cliente envía una solicitud HTTP a un servidor, el servidor responde con un código de estado de tres dígitos seguido de una frase de razón legible para humanos. El primer dígito del código de estado define la clase de la respuesta. Los dos dígitos restantes no tienen un rol de categorización específico pero proporcionan granularidad dentro de cada clase. Los códigos de estado son definidos por la Autoridad de Números Asignados de Internet (IANA) basados en especificaciones publicadas en documentos RFC. A partir de 2025, hay más de 70 códigos de estado HTTP registrados oficialmente, aunque solo unos 30-40 están en uso común.
Referencia Rápida
| Clase | Categoría | Significado |
|---|---|---|
| 1xx | Informativo | Solicitud recibida, continuando procesamiento |
| 2xx | Éxito | Solicitud recibida, entendida y aceptada |
| 3xx | Redirección | Se necesita acción adicional para completar la solicitud |
| 4xx | Error del Cliente | Solicitud tiene sintaxis incorrecta o no puede cumplirse |
| 5xx | Error del Servidor | El servidor falló al cumplir una solicitud válida |
1xx - Informativo
Estos códigos indican que el servidor ha recibido los encabezados de la solicitud y el cliente debe continuar enviando el cuerpo, o que el servidor está cambiando a un protocolo diferente. Estas son respuestas provisionales sin contenido de cuerpo real.
| Código | Nombre | Descripción |
|---|---|---|
| 100 | Continuar | Servidor recibió encabezados, el cliente debe continuar enviando el cuerpo |
| 101 | Cambiando Protocolos | Servidor está cambiando de protocolo (ej., actualizando a WebSocket) |
| 102 | Procesando | Servidor está procesando la solicitud pero aún no hay respuesta (WebDAV) |
| 103 | Indicaciones Tempranas | Precargar recursos mientras el servidor prepara la respuesta, usado para optimización de rendimiento |
El estado 100 Continuar se usa a menudo junto con el encabezado de solicitud Expect: 100-continue. Cuando un cliente envía este encabezado, espera confirmación antes de enviar una carga útil grande. Esto evita el desperdicio de ancho de banda cuando el servidor va a rechazar la solicitud basándose solo en los encabezados.
101 Cambiando Protocolos es la piedra angular de las conexiones WebSocket. Cuando un cliente envía un encabezado Upgrade: websocket, el servidor responde con 101 para confirmar el cambio de protocolo de HTTP a WebSocket, habilitando la comunicación bidireccional en tiempo real.
103 Indicaciones Tempranas es una adición relativamente reciente (RFC 8297) que permite a los servidores enviar indicaciones al navegador sobre recursos críticos (CSS, JavaScript, fuentes) que serán necesarios para la respuesta final. Esto permite al navegador comenzar a precargar estos recursos antes de que la respuesta completa esté lista, mejorando el rendimiento percibido.
2xx - Éxito
Estos códigos indican que la solicitud del cliente fue recibida, entendida y aceptada con éxito. Esta es la categoría que todo desarrollador espera ver.
| Código | Nombre | Descripción |
|---|---|---|
| 200 | OK | Respuesta de éxito estándar para solicitudes GET, POST, PUT |
| 201 | Creado | Recurso creado exitosamente, típicamente en respuesta a POST |
| 202 | Aceptado | Solicitud aceptada para procesamiento pero aún no completada |
| 203 | Información No Autoritativa | Respuesta de una fuente externa, no del servidor de origen |
| 204 | Sin Contenido | Éxito, pero no hay cuerpo de respuesta que devolver |
| 205 | Restablecer Contenido | Indica al navegador que limpie el formulario/documento actual |
| 206 | Contenido Parcial | Recurso parcial devuelto, usado para solicitudes de rango y descargas reanudables |
| 207 | Multi-Estado | Múltiples códigos de estado para múltiples recursos (WebDAV) |
| 208 | Ya Informado | Recurso ya fue informado (WebDAV) |
200 OK es el código de estado más común. Indica que la solicitud tuvo éxito y el cuerpo de la respuesta contiene los datos solicitados. Para solicitudes GET, el cuerpo contiene la representación del recurso. Para solicitudes POST, contiene el resultado de la acción.
201 Creado debe devolverse cuando se crea un nuevo recurso como resultado de una solicitud POST o PUT. La respuesta debe incluir un encabezado Location que apunte a la URL del recurso recién creado. Por ejemplo, después de crear un nuevo usuario, devuelve 201 Creado con la URL del perfil del usuario en el encabezado Location.
204 Sin Contenido es útil para solicitudes DELETE o actualizaciones PUT donde el cuerpo de la respuesta está vacío. Indica al cliente que la operación tuvo éxito pero no hay nada que devolver. El navegador no debe cambiar su vista de documento actual.
3xx - Redirección
Estos códigos indican que el cliente necesita realizar una acción adicional para completar la solicitud, generalmente siguiendo una redirección a una URL diferente.
| Código | Nombre | Descripción |
|---|---|---|
| 300 | Múltiples Opciones | Múltiples representaciones posibles, el cliente debe elegir |
| 301 | Movido Permanentemente | El recurso tiene una nueva URL permanente, actualizar marcadores |
| 302 | Encontrado | Redirección temporal, seguir usando la URL original en el futuro |
| 303 | Ver Otro | Redirigir a una URL diferente usando el método GET |
| 304 | No Modificado | Recurso no modificado, usar versión en caché |
| 307 | Redirección Temporal | Redirección temporal preservando el método HTTP |
| 308 | Redirección Permanente | Redirección permanente preservando el método HTTP |
La distinción entre 301 y 302 es crítica para el SEO. Los motores de búsqueda tratan las redirecciones 301 como permanentes, transfiriendo la autoridad de ranking de la URL original a la nueva URL. Una redirección 302 no transfiere valor SEO porque se espera que la URL original regrese.
304 No Modificado se usa junto con encabezados de solicitud condicionales como If-Modified-Since o If-None-Match (ETags). Cuando el cliente tiene una versión en caché de un recurso, puede preguntar al servidor si el recurso ha cambiado. Si no ha cambiado, el servidor devuelve 304 sin cuerpo, ahorrando ancho de banda en ambos lados.
307 y 308 preservan el método HTTP usado en la solicitud original, a diferencia de 302 y 301 que pueden cambiar POST a GET. Esta distinción importa para endpoints de API donde preservar el método de solicitud es importante.
4xx - Error del Cliente
Estos códigos indican que el cliente envió una solicitud problemática. El error está del lado del cliente — el servidor está funcionando correctamente.
| Código | Nombre | Descripción |
|---|---|---|
| 400 | Solicitud Incorrecta | Sintaxis o parámetros de solicitud inválidos |
| 401 | No Autorizado | Se requiere autenticación o ha fallado |
| 402 | Pago Requerido | Reservado para uso futuro, raramente implementado |
| 403 | Prohibido | Cliente autenticado pero no tiene permiso |
| 404 | No Encontrado | El recurso solicitado no existe |
| 405 | Método No Permitido | El método HTTP no está soportado para esta URL |
| 406 | No Aceptable | No se puede generar respuesta que coincida con encabezados Accept |
| 407 | Autenticación de Proxy | Debe autenticarse con un proxy primero |
| 408 | Tiempo de Espera Agotado | El servidor agotó el tiempo esperando la solicitud |
| 409 | Conflicto | La solicitud entra en conflicto con el estado actual del servidor |
| 410 | Desaparecido | Recurso eliminado permanentemente, sin dirección de reenvío |
| 411 | Longitud Requerida | El encabezado Content-Length es requerido |
| 412 | Condición Previa Fallida | Los encabezados de solicitud condicionales evaluaron falso |
| 413 | Carga Útil Demasiado Grande | El cuerpo de la solicitud excede los límites del servidor |
| 414 | URI Demasiado Largo | La URL excede la longitud máxima permitida por el servidor |
| 415 | Tipo de Medio No Soportado | Content-Type no soportado por el servidor |
| 416 | Rango No Satisfactorio | El encabezado Range no puede satisfacerse |
| 417 | Expectativa Fallida | El encabezado Expect no puede satisfacerse |
| 422 | Entidad No Procesable | El cuerpo de la solicitud es sintácticamente correcto pero semánticamente inválido |
| 423 | Bloqueado | El recurso está bloqueado (WebDAV) |
| 424 | Dependencia Fallida | Solicitud falló porque otra solicitud falló (WebDAV) |
| 426 | Actualización Requerida | El cliente debe cambiar a un protocolo diferente |
| 428 | Condición Previa Requerida | El servidor de origen requiere que la solicitud sea condicional |
| 429 | Demasiadas Solicitudes | El cliente ha excedido los límites de tasa |
| 431 | Encabezados de Solicitud Demasiado Grandes | Los encabezados exceden el tamaño máximo |
| 451 | No Disponible por Razones Legales | Recurso bloqueado debido a demandas legales |
400 Solicitud Incorrecta es el comodín para errores del cliente. Úsalo cuando el servidor no pueda procesar la solicitud debido a sintaxis mal formada, parámetros de consulta inválidos o un cuerpo de solicitud mal formado. Siempre incluye un mensaje de error descriptivo en el cuerpo de la respuesta para ayudar a los clientes a solucionar el problema.
401 No Autorizado se devuelve cuando el cliente no ha proporcionado credenciales de autenticación válidas. La respuesta debe incluir un encabezado WWW-Authenticate indicando el esquema de autenticación (Basic, Bearer, Digest, etc.) que espera el servidor.
403 Prohibido difiere de 401 en que el cliente está autenticado pero no tiene permisos suficientes. Por ejemplo, un usuario normal que intenta acceder a un endpoint de administración debería recibir 403, no 401.
404 No Encontrado es el código de estado HTTP más conocido. Indica que el servidor no puede encontrar el recurso solicitado. Ten cuidado de no revelar si el recurso existe pero está oculto — devolver 404 tanto para recursos inexistentes como prohibidos es una práctica de seguridad común.
409 Conflicto es útil para APIs REST cuando hay un conflicto de versión. Por ejemplo, cuando una solicitud PUT actualiza un recurso que ha sido modificado por otro usuario desde que el cliente lo obtuvo por última vez.
429 Demasiadas Solicitudes es esencial para la limitación de tasa de API. Debe incluir un encabezado Retry-After indicando cuánto tiempo debe esperar el cliente antes de hacer otra solicitud.
5xx - Error del Servidor
Estos códigos indican que el servidor encontró un error al procesar una solicitud válida. El problema está del lado del servidor.
| Código | Nombre | Descripción |
|---|---|---|
| 500 | Error Interno del Servidor | Error genérico del servidor, sin detalles específicos disponibles |
| 501 | No Implementado | El servidor no soporta la funcionalidad solicitada |
| 502 | Puerta de Enlace Incorrecta | El servidor upstream devolvió una respuesta inválida |
| 503 | Servicio No Disponible | Servidor temporalmente no disponible (sobrecargado o caído) |
| 504 | Tiempo de Espera de Puerta de Enlace | El servidor upstream no respondió a tiempo |
| 505 | Versión HTTP No Soportada | El servidor no soporta la versión del protocolo HTTP utilizada |
| 506 | Variante También Negocia | Error de configuración del servidor en la negociación de contenido |
| 507 | Almacenamiento Insuficiente | El servidor no puede almacenar la representación (WebDAV) |
| 508 | Bucle Detectado | El servidor detectó un bucle infinito (WebDAV) |
| 509 | Límite de Ancho de Banda Excedido | No es un estado oficial, usado por algunos módulos Apache |
| 510 | No Extendido | Se requieren extensiones adicionales para la solicitud |
| 511 | Autenticación de Red Requerida | El cliente debe autenticarse para acceder a la red |
500 Error Interno del Servidor es el comodín para fallos del lado del servidor. Nunca debe devolverse para solicitudes de cliente inválidas — esas deben usar códigos 4xx. Una respuesta 500 indica que algo salió mal en la lógica de procesamiento del servidor.
502 Puerta de Enlace Incorrecta típicamente ocurre cuando un proxy o balanceador de carga recibe una respuesta inválida de un servidor upstream. Por ejemplo, si un servidor de aplicaciones se cae o devuelve una respuesta mal formada, el proxy inverso devuelve 502 al cliente.
503 Servicio No Disponible se usa cuando el servidor está temporalmente sobrecargado o caído por mantenimiento. Incluye un encabezado Retry-After para que los clientes y rastreadores sepan cuándo reintentar. Esto se ve comúnmente durante ventanas de despliegue o picos de tráfico.
504 Tiempo de Espera de Puerta de Enlace ocurre cuando un servidor en una cadena (ej., un proxy inverso hablando con un servidor de aplicaciones) no recibe una respuesta oportuna de otro servidor. El tiempo de espera predeterminado es típicamente de 30 a 120 segundos dependiendo de la infraestructura.
Guía de Uso de Códigos de Estado
| Escenario | Código de Estado |
|---|---|
| Solicitud GET exitosa | 200 |
| POST exitoso (creado) | 201 |
| DELETE exitoso | 204 |
| Validación de formulario falla | 422 |
| Usuario no ha iniciado sesión | 401 |
| Usuario no tiene permiso | 403 |
| Recurso no encontrado | 404 |
| Límite de tasa excedido | 429 |
| Caída del servidor | 500 |
| Endpoint API aún no implementado | 501 |
| Mantenimiento temporal | 503 |
Mejores Prácticas para Usar Códigos de Estado HTTP
Usa siempre el código de estado más específico que se aplique a tu situación. Devolver un error 500 genérico cuando un 503 o 504 es más apropiado dificulta la depuración para los consumidores de la API. Incluye mensajes de error descriptivos e identificadores de error únicos en los cuerpos de tus respuestas para ayudar con la depuración. Para APIs REST, considera también incluir un código de error legible por máquina que los clientes puedan manejar mediante programación. Finalmente, asegúrate de que tus respuestas de error respeten el tipo de contenido solicitado a través de la negociación de contenido — devuelve JSON para clientes API y HTML para páginas de error basadas en navegador.
Usa la herramienta Referencia de Códigos de Estado HTTP para consultas rápidas cada vez que necesites recordar el significado o el uso adecuado de cualquier código de estado HTTP.
