El elemento código de estado es un entero de tres dígitos, resultado del intento por entender y satisfacer la demanda. Estos códigos se definen debajo. El Mensaje de Estado se pensó para dar una descripción textual corta del código de estado.

1xx: Informational (informativo)
    La Demanda se recibió, mientras sigue continuando el proceso.

2xx: Success (acierto)
    La acción fue recibida con éxito, se entendió, y se aceptó.

3xx: Redirection (redirección)
    Una acción adicional debe ser iniciada para completar la demanda.

4xx: Client Error (error de cliente)
    La demanda contiene una sintaxis mala o no puede cumplirse.

5xx: Server Error (error de servidor)
    El servidor no cumplió una demanda aparentemente válida.

Informational 1xx
    Esta clase de código de estado indica una contestación provisional, consistente únicamente en el estado de línea y en títulos optativos; se termina con una línea vacía. Desde HTTP/1.0 no se debería definir ningún código de estado 1xx, los servidores NO DEBEN enviar una 1xx contestación a un cliente de HTTP/1.0 excepto bajo condiciones experimentales.

100 Continue (continúa)
    El cliente puede continuar con su demanda. Esta contestación interna se usa para informar al cliente que la parte inicial de la demanda se ha recibido y no se ha rechazado todavía por el servidor. El cliente DEBERÍA continuar enviando el resto de la demanda o, si la demanda ya se ha completado, ignorar esta contestación. El servidor debe enviar una última contestación después de que la demanda se haya completado.

101 Switching Protocols (cambiando protocolos)
    El servidor entiende y está dispuesto a obedecer la demanda del cliente, vía Actualización del título del campo del mensaje, por un cambio en el protocolo de la aplicación que se usa en esta conexión. El servidor cambiará los protocolos a aquellos definidos inmediatamente por la Actualización del título del campo de la contestación después de la línea vacía en que termina la respuesta 101.
    El protocolo sólo debe cambiarse cuando es ventajoso hacerlo. Por ejemplo, cambiarlo a una versión más nueva de HTTP es ventajoso respecto de versiones más viejas, cambiándolo a un tiempo real, el protocolo síncrono puede resultar ventajoso cuando se usan recursos de estas características.

Successful 2xx (satisfactorio)
    Todos los códigos de la contestación que empiezan con 2xx indican que la demanda fue recibida con éxito, se entendió, y se aceptó.

200 OK (conforme)
    The request has succeeded (la demanda tuvo éxito).

201 Created (creado)
    La demanda se ha cumplido y se ha producido un nuevo recurso. El recurso recientemente creado puede ser referido a la URL(s) devuelta en la entidad contestadora, con la URL más específica para el recurso dado por una localización del título del campo. El servidor del origen debe crear el recurso antes de devolver el código de estado 201. Si la acción no puede llevarse a cabo inmediatamente, el servidor debe responder con la respuesta 202 (Aceptado).

202 Accepted (aceptado)
    La demanda se ha aceptado para su proceso, pero éste no se ha completado. La demanda PUEDE o no puede actuarse en el futuro, aunque puede desaprobarse cuando realmente el proceso tenga lugar. No es fácil re-enviar un código de estado de un funcionamiento asíncrono como este.
    La contestación 202 es intencionalmente de no-compromiso. Su propósito es permitir un servidor para aceptar una demanda de algún otro proceso (quizás un proceso de lotes que sólo se ejecuta una vez por día) sin exigir que la conexión del usuario al servidor persista hasta que el proceso se complete. La entidad que devuelve esta contestación DEBERIA incluir una indicación del estado actual de la demanda y/o un indicador a monitor de estado, o alguna estimación de cuando el usuario puede esperar cumplir la demanda.

203 Non-Authoritative Information (Información no autorizable)
    La meta-información devuelta en el título de la entidad no se halla definitiva como disponible en el servidor de origen, pero se recopila desde uno local o de un tercero. El presentado puede ser un subconjunto o "superset" de la versión original. Por ejemplo, la inclusión de la información de la anotación local sobre el recurso, puede producir un "superset" de metainformation conocido por el servidor del origen. El uso de este código de respuesta no se requiere y sólo es apropiado cuando la contestación, por otra parte, sería 200 (OK).

204 No Content (sin contenido)
    El servidor ha cumplido la demanda pero no hay nueva información para remitir. Si el cliente es un agente del usuario, NO DEBERÍA CAMBIAR el documento que causó la solicitud para ser enviada. Se piensa principalmente que esta contestación permite la entrada a acciones que tengan lugar sin causar un cambio al documento activo del agente del usuario. La contestación puede incluir la nueva meta-información en la forma de título de entidad que debería aplicarse actualmente al documento del usuario.

205 Reset Content (Volumen restablecido)
    El servidor ha cumplido la demanda y el agente del usuario debe restablecer la vista del documento que causó la demanda para ser enviada. Se piensa principalmente que esta contestación permite la entrada para acciones que tienen lugar vía usuario, siguida por un aclaramiento de la forma en que la entrada se da para que el usuario pueda comenzar otra acción fácilmente. La contestación no debe incluir una entidad.

206 Partial Content (Contenido parcial)
    El servidor ha cumplido GESTIÓN parcial DE demanda para el recurso. La demanda debe de haber incluido un campo de título de Rango (sección 14.36) indicando el rango deseado. La contestación o debe incluir un campo de título de rango-contenido (sección 14.17) indicando el rango incluido con esta contestación, o un tipo de contenido como multipart/byteranges incluyendo los campos del rango de contenido para cada parte. Si el multipart/byteranges no se usa, el campo de título de longitud de contenido en la contestación debe emparejar el número real de Octetos transmitido en el cuerpo del mensaje.
    Una caché que no soporta el Rango y los títulos del rango de contenido no deben "cachear" 206 (Parcial) las contestaciones.

Redirection 3xx (redireccionamiento)
    Esta clase de código de estado indica que esa acción extensa necesita ser emprendida por el agente del usuario para cumplir la demanda. La acción requerida puede llevarse a cabo por el agente del usuario sin la interacción con el usuario y únicamente si el método usado en la segunda demanda tiene GET o HEAD. Un agente del usuario no debe redireccionar automáticamente una solicitud más de 5 veces, ya que los tales redireccionamientos normalmente suponen un bucle infinito.

300 Multiple Choices (Opciones múltiples)
    El recurso pedido corresponde a cualquiera configurado en un juego de representaciones, cada uno con su propia situación específica, y la información de la gestión (sección 12) está proporcionándose para que el usuario (o agente del usuario) puede seleccionar una representación preferida y puede remitir su demanda a esa situación. A menos que sea una demanda de HEAD, la contestación debeRÍA incluir una entidad que contenga una lista de las características del recurso y localización(es) desde las que el usuario o agente del usuario pueda escoger la más apropiada.
    El formato de la entidad se especifica por el tipo de los medios de comunicación cedido en el título del tipo de contenido del campo. Dependiendo del formato y de las capacidades del del agente del usuario, la selección de la opción más apropiada puede realizarse automáticamente. Sin embargo, esta especificación no define ningún estándar para esa selección automática.
    Si el servidor tiene una opción preferida de representación, debe incluir la URL específico para esa representación en el campo de localización; los agentes del usuario pueden usar el valor de campo de situación (lozalización) mediante redirección automática. Esta contestación es el cacheable a menos que se indique lo contrario.

301 Moved Permanently (movido permanentemente)
    El recurso pedido se ha asignado unos nuevos URI permanentes y cualquier referencia futura a este recurso debería hacerse usando uno de los URIs devueltos. Los clientes con capacidades de edición del enlace (link) deben re-enlazar las referencias automáticamente hacia la URI solicitada, hacia una o más de las nuevas referencias retornadas por el servidor cuando sea posible. Esta contestación es el cacheable a menos que se indique lo contrario.
Si el nuevo URI es una localización, su URL debe darse por el campo de la localización contestada. A menos que el método de la demanda sea HEAD, la entidad de la respuesta debería contener una corta nota de hipertexto con un hyperlink al nuevo URI(s).
    Si el código de estado 301 se recibe en la contestación a una demanda de otra manera que GET o HEAD, el agente del usuario no debe remitir la demanda automáticamente a menos que pueda confirmarse por el usuario, ya que esto podría cambiar las condiciones bajo que las que la demanda fue emitida.
    Nota: Cuando se remite una demanda de POST automáticamente después de recibir un código de estado 301, algunos agentes existentes de usuario HTTP/1.0 lo cambiarán erróneamente a una demanda GET.

302 Moved Temporarily (movido temporalmente)
    El recurso pedido reside temporalmente bajo un URL diferente. Ya que que la redirección puede alterarse en ocasiones, el cliente debe continuar usando la solicitud-URL para futuras peticiones. Esta contestación es sólo cacheable si indicó por un Cache-Control o un campo título que expira.
Si el nuevo URI es una localización, su URL debe darse por el campo de la misma en la contestación. A menos que el método de la demanda sea HEAD, la entidad de la contestación debe contener una corta nota de hipertexto con un hyperlink al nuevo URI(s).
    Si el código de estado 302 se recibe en la contestación a una otra demanda que GET o HEAD, el agente del usuario no debe remitir la demanda automáticamente a menos que puede confirmarse por el usuario, ya que que esto podría cambiar las condiciones bajo que la demanda se emitió.
Nota: Cuando se redirecciona automáticamente una petición POST después de recibir un código de estado 302, algunos existentes agentes de usuario HTTP/1.0 lo cambiarán erróneamente en una petición GET.

303 See Other (se ve otro)
    La contestación a la demanda puede encontrarse bajo un URI diferente y debe recuperarse usando un método GET en ese recurso. Este método existe principalmente para permitir la salida de un Script POST activado para redirigir al agente del usuario a un recurso seleccionado. El nuevo URI no es una referencia suplente para el recurso originalmente pedido. La contestación 303 no es cacheable, pero la contestación a la segunda petición (redireccionada) puede ser cacheable.
    Si el nuevo URI es una localización, su URL debería de darse por localización del campo en la contestación. A menos que el método de la demanda sea HEAD, la entidad de la contestación debe contener una corta nota del hipertexto con un hyperlink al nuevo URI(s).

304 Not Modified (no modificado)
    Si el cliente ha realizado un GET condicional la demanda y el acceso se permite, pero el documento no se ha modificado, el servidor debería esponder con este código de estado. La contestación no debe contener un cuerpo de mensaje.
    La contestación debe incluir los títulos de campo siguientes:
Date (la fecha) ETag y/o Content-Location, si el título se hubiera enviado en una respuesta 200 a la misma demanda Expires, Cache-Control, and/or Vary, si el valor del campo pudiera diferir del enviado en contestación anterior para la misma variante.
    Si el condicional GET usó un potente validator de caché, la contestación no debería incluir otros títulos dde la entidad.
    Por otra parte (es decir, el condicional usó validator débil), la contestación no debe incluir otros títulos de entidad; esto previene las inconsistencias entre los cuerpo de entidad cacheados y actualización de títulos.
    Si una contestación 304 indica una entidad no habitualmente cacheada, entonces la caché debe desatender la contestación y debe repetir la petición sin el condicional.
    Si una caché usa una contestación 304 recibida para poner al día una entrada de caché, ésta debe poner al día la entrada para reflejar nuevos valores del campo cedidos en la respuesta.
    La contestación 304 no debe incluir un cuerpo de emnsaje, y así siempre se termina por la primera línea vacía después de los campos del título.

305 Use Proxy
    El recurso pedido debe accederse a través del Proxy dado por el campo de localización. Este, da el URL del Proxy. Se espera que el destinatario repita la demanda vía Proxy.

Client Error 4xx (Error de cliente 4xx)
    La clase 4xx del código de estado está pensada para casos en que el cliente parece haber errado. Excepto al responder a una demanda HEAD, el servidor debe incluir una explicación de la situación del error, y si es una condición temporal o permanente. Estos códigos de estado son aplicables a cualquier método de la demanda.
    Los agentes del usuario deberían mostrar cualquier entidad incluida para el usuario.
    Nota: Si el cliente está enviando los datos, una aplicación del servidor usando TCP debería tener cuidado para asegurar que el cliente reconoce el recibo del packet(s) conteniendo la contestación, antes de que el servidor cierre la conexión de la entrada. Si el cliente continúa enviando los datos al servidor después del cierre, el stack de TCP del servidor enviará un reset al cliente que puede borrar las entradas no reconocidas del cliente antes de que puedan leerse e interpretarse por la aplicación HTTP.

400 Bad Request (Mala petición)
    La demanda no pudo entenderse por el servidor debido a sintaxis incorrecta. El cliente no debe repetir la petición sin haber hecho algunas modificaciones.

401 Unauthorized (desautorizado)
    La demanda requiere la autenticación del usuario. La contestación debe incluir un campo del título WWW-auténtico que contenga una recusación aplicable al recurso pedido. El cliente puede repetir la petición con el campo de título de Autorización conveniente. Si la demanda ya incluyera las credenciales de la Autorización, entonces la contestación 401 indica que esa autorización se ha negado para esas credenciales. Si la contestación 401 contiene la misma recusación como la contestación anterior, y el agente del usuario ya ha intentado por lo menos una vez la autenticación, entonces el usuario debería presentarse la entidad que se dio en la contestación, desde que esa entidad puede incluir la información de diagnóstico pertinente.

402 Payment Required (pago requirido)
    Este código es reservado para uso futuro.

403 Forbidden (prohibido)
    El servidor entendió la demanda, pero está negándose a cumplirlo. La autorización no ayudará y la demanda no debe repetirse. Si el método de la demanda no fuera HEAD y el servidor desea hacer público por qué la demanda no se ha cumplido, debe describir la razón para la negativa en la entidad.     Este código de estado normalmente se usa cuando el servidor no desea revelar exactamente por qué la demanda se ha negado, o cuando ninguna otra contestación es aplicable.

404 Not Found (no encontrado)
    El servidor no ha encontrado nada coincidente con la solicitud URI. No se da indicación alguna de si la condición es temporal o permanente.
    Si el servidor no desea hacer esta información disponible al cliente, el código de estado 403 (Prohibido) puede usarse a cambio. El código de estado 410 (gone = marchado) podría ser usado si el servidor sabe, a través de algunos mecanismos internos configurables, que un recurso antiguo está permanentemente indisponible y no tiene ninguna dirección remitente.

405 Method Not Allowed (método no permitido)
    El método especificado en la línea de solicitud no se permite para el recurso identificado por el Demanda-URI. La contestación debe incluir un título ALLOW que contenga una lista de métodos válidos para el recurso pedido.

406 Not Acceptable (no aceptable)
    El recurso identificado por la demanda sólo es susceptible de entidades de generadoras de contestación que tengan las características capaces de no aceptar, de acuerdo a la aceptación de títulos enviados en la demanda.
    A menos que sea una demanda HEAD, la contestación debe incluir una entidad que contenga una lista de características de la entidad disponibles y lugares desde los que el usuario o agente del usuario puede escoger el más apropiado. El formato de la entidad se especifica por el tipo de los medios de comunicación cedido el campo de título del tipo de contenido. Dependiendo del formato y de las capacidades del agente del usuario, la selección de la opción más apropiada puede realizarse automáticamente. Sin embargo, esta especificación no define ningún standard para tal selección automática.
    Nota: Se permite a los servidores de HTTP/1.1 devolver contestaciones que no son aceptables de acuerdo con los títulos de aceptación enviados en la demanda. En algunos casos, esto puede ser incluso preferible a enviar una respusta 406. Se alienta a que los agentes del usuario inspeccionen los títulos de una contestación entrante para determinar si es aceptable. Si la contestación pudiera ser inaceptable, el agente del usuario debería detener temporalmente la recepción de más datos y preguntar al usuario para una decisión en las acciones posteriores.

407 Proxy Authentication Required (autentificación Proxy requerida)
    Este código es similar a 401 (Desautorizado), pero indica que el cliente debe autentificarse primero con el Proxy. Este, debe devolver un campo de título de autentificación Proxy que contenga una credencial aplicable al Proxy para el recurso pedido. El cliente puede repetir la demanda con un campo título de autorización Proxy conveniente.

408 Request Timeout (interrupción de la demanda)
    El cliente no produjo una demanda dentro del tiempo que en el servidor espera. El cliente puede repetir la demanda sin modificaciones un momento más tarde.

409 Conflict (conflicto)
    La demanda no podría completarse debido a un conflicto con el estado actual del recurso. Este código sólo se permite en situaciones dónde se espera que el usuario podría llegar a resolver el conflicto y repetir la demanda. El cuerpo de la contestación debe incluir bastante información para que el usario pueda reconocer la fuente del conflicto. Con suerte, la entidad de la contestación podría incluir bastante información para que el usuario o agente del usuario logre arreglar el problema; sin embargo, eso no puede ser posible y no está requerido.
    La mayoría de los conflictos suelen ocurrir en la contestación a una demanda PUT. El servidor puede usar la contestación 409 para indicar que no puede completar la demanda. En este caso, la entidad de la contestación debe contener una lista de las diferencias entre las dos versiones en un formato definido por el tipo de contenido de la contestación.

410 Gone (ido, marchado)
    El recurso pedido ya no está disponible en el servidor y ninguna dirección que se remite es conocida. Esta condición debe ser considerada permanente. Los clientes con las capacidades de corrección de link deben anular las referencias a la demanda URI después de la aprobación del usuario.     Si el servidor no sabe, o no tiene la facilidad para determinar, si la condición es o no permanente, el código de estado 404 (no encontrado) debería de usarse a cambio. Esta contestación es el cacheable a menos que se indique de otro lado.
    Se piensa principalmente que la contestación 410 ayuda la tarea de mantenimiento de la Web notificando al destinatario que el recurso es intencionalmente indisponible y que los dueños del servidor desean que los links remotos a ese recurso se quiten. Semejante evento es común por tiempo limitado, para los servicios promocionales y para recursos que pertenecen a individuos que ya no trabajan más el Site del servidor. No es necesario marcar todos los recursos permanentemente indisponibles como "idos" o guardar la marca por algún erspacio de tiempo; eso se deja a la discreción del dueño del servidor.

411 Length Required (longitud requerida)
    El servidor se niega a aceptar la demanda sin una Longitud de Volumen definida. El cliente puede repetir la demanda si agrega un campo título de longitud de contenido válido, que contenga la longitud del cuerpo del mensaje en el mensaje de la demanda.

412 Precondition Failed (condición previa fallada)
    La condición previa cedida en uno o más de los campos del título de petición evaluó a falso cuando se probó en el servidor. Este código de la contestación le permite al cliente poner las condiciones previas en la meta-información del recurso actual (los datos de campo de título) y así previene el método pedido de aplicarse a un recurso de otra manera que se pensó.

413 Request Entity Too Large (entidad de la demanda demasiado grande)
    El servidor está negándose a procesar una demanda porque la entidad de la demanda es más grande de lo que el servidor desea o es capaz de procesar. El servidor puede cerrar la conexión para impedirle al cliente continuar la demanda.
    Si la condición es temporal, el servidor debe incluir un Reintento después de que el campo del título indique que es temporal y después de qué hora el cliente puede probar de nuevo.

414 Request-URI Too Long (demanda-URI Demasiado grande)
    El servidor está rechazando la demanda porque la petición-URI es más grande de lo que el servidor está dispuesto interpretar. Esta rara condición solamente ocurre cuando un cliente ha convertido una demanda del POST inadecuadamente a una GET con una información larga, cuando el cliente ha descendido en un URL "agujero negro" de redirección (por ejemplo, un prefijo de URL redireccionado que apunta a un sufijo de sí mismo), o cuando el servidor está bajo el ataque por un cliente que intenta aprovecharse de agujeros de seguridad presentes en algunos servidores que usan buffers de longitud fija para leer o manipular la demanda URI.

415 Unsupported Media Type (medios no soportados)
El servidor está rechazando la demanda porque la entidad de la demanda está en un formato no apoyado por el recurso pedido para el método solicitado.

Server Error 5xx (error de servidor 5xx)
    La respuesta de código de estado que comienza con el dígito "5" indican casos en que el servidor es consciente que ha errado o ha sido incapaz de ejecutar la solicitud. Excepto cuando se responde a una demanda HEAD, el servidor debe incluir una entidad que contiene una explicación de la situación del error, y si es una condición temporal o permanente. los agentes del usuario deberían mostrar cualquier entidad al usuario. Éstos códigos de respuesta son aplicables a cualquier método de la demanda.

500 Internal Server Error (Error interno del servidor)
    El servidor encontró una condición inesperada que le impidió   cumplir la demanda.

501 Not Implemented (no se llevó a cabo)
    El servidor no soporta la funcionalidad que se exigió paracumplir la demanda. Ésta es la contestación apropiada cuando el servidor no reconoce el método de la demanda y no es capaz de dar soporte para el recurso.

502 Bad Gateway (entrada mala)
    El servidor, mientras actuaba como una Gateway o Proxy, recibió una contestación inválida desde el servidor del Upstream y accedió intentando cumplir la demanda.

503 Service Unavailable (servicio no disponible)
    El servidor es actualmente incapaz de ocuparse de la demanda debido a una sobrecarga o mantenimiento temporal del mismo. La implicación es que ésta es una condición temporal que se aliviará después de algún retraso. Si éste es conocido, la longitud del retraso puede indicarse en un título de reintentarse después. Si no se da ningún reintento después (Retry-After), el cliente debe desocuparse de la contestación como se haría para una respuesta 500.
    Nota: La existencia del código de estado 503 no implica que un servidor deba de usarlo cuando se vea cargado excesivamente. Algunos servidores pueden reusar la conexión simplemente.

504 Gateway Timeout (interrupción de entrada)
    El servidor, mientras actuaba como un Gateway o Proxy, no recibió una contestación oportuna del servidor Upstream que accedió intentando completar la demanda.

505 HTTP Version Not Supported (versión de HTTP no soportada)
    El servidor no soporta, o se niega a soportar, el protocolo de versión HTTP que se usó en el mensaje de la demanda. El servidor está indicando que es incapaz o reacio a completar la demanda usando la misma versión mayor que el cliente, con este mensaje de error. La contestación debe contener una entidad que describa por qué esa versión no se soporta y qué otros protocolos se soportan por ese servidor.