¿Qué son las cabeceras HTTP? Las más comunes, explicadas

Abres una tienda online y aparece en tu idioma, mantiene tu sesión iniciada y carga rápido desde una caché. Nada de eso lo decidió la propia página. Antes de que llegue su primera línea, tu navegador y el servidor intercambian una docena de líneas cortas sobre quién pregunta, qué acepta y qué va a volver. Esas líneas son las cabeceras HTTP.

Este artículo muestra una solicitud y una respuesta reales capturadas con curl, las cabeceras que más vas a encontrar, si los nombres distinguen entre mayúsculas y minúsculas, y cómo leer las cabeceras en Chrome y con curl. Al final verás las cabeceras de seguridad para propietarios de sitios, las cabeceras que un proxy añade o lee y seis preguntas frecuentes.

¿Qué son las cabeceras HTTP?#

Las cabeceras HTTP son datos adicionales, cada uno con su nombre, que se envían con una solicitud o una respuesta antes del propio contenido. El RFC 9110, el estándar que define HTTP, llama a los campos enviados antes del contenido «header fields», o simplemente headers (cabeceras). Cada cabecera es una línea con un nombre, dos puntos y un valor, como Accept-Language: es-ES.

Todo mensaje HTTP tiene la misma forma: una primera línea, las cabeceras, una línea vacía y, si lo hay, el cuerpo. En una solicitud, la primera línea indica el método y la ruta (GET /); en una respuesta, el código de estado (200 OK). El cuerpo es la página, la imagen o los datos; las cabeceras describen ese cuerpo y a las dos partes del intercambio.

Las cabeceras de solicitud van de tu navegador o tu app al servidor, y las de respuesta hacen el camino inverso. La referencia de cabeceras HTTP de MDN recoge todas las cabeceras estándar ordenadas por grupos. Los nombres que empiezan por X- son extensiones caseras; esa costumbre de nombrarlas así se desaconsejó oficialmente en 2012, pero muchos de esos nombres siguen en uso.

¿Cómo funcionan las cabeceras en una solicitud y una respuesta?#

Cargar una página consiste en una solicitud y una respuesta, cada una con sus propias cabeceras:

1. Tu navegador se conecta al servidor. Si la dirección empieza por https://, primero establece el cifrado.
2. Envía la línea de solicitud y las cabeceras de solicitud: GET /, y después Host, User-Agent, Accept, Accept-Language y las cookies que tenga guardadas para ese sitio.
3. Una línea vacía cierra las cabeceras. Un formulario o una llamada a una API añade un cuerpo detrás.
4. El servidor lee las cabeceras: Host elige el sitio, Accept-Language el idioma, Cookie el usuario que tiene la sesión iniciada.
5. Responde con una línea de estado y cabeceras de respuesta, como 200 OK y Content-Type, seguidas de una línea vacía y del cuerpo.
6. El navegador actúa en consecuencia: muestra la página, guarda las cookies, almacena una copia en caché o sigue una redirección.

¿Cómo son una solicitud y una respuesta HTTP reales?#

Aquí tienes un intercambio con example.com hecho con curl -v. curl es una herramienta de línea de comandos que descarga direcciones web y viene incluida en Windows 10 y 11, en macOS y en la mayoría de los sistemas Linux; -v (verbose, detallado) imprime los dos lados. Lo ejecutamos en Windows 11 el 15 de noviembre de 2026 y recortamos la salida para dejar solo las cabeceras:

> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 15 Nov 2026 15:40:29 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: cloudflare
< last-modified: Thu, 12 Nov 2026 21:56:22 GMT
< allow: GET, HEAD
< Accept-Ranges: bytes
< Age: 6679
< cf-cache-status: HIT
< alt-svc: h3=":443"; ma=86400

Las líneas que empiezan por > son lo que envió curl, y las que empiezan por <, lo que respondió el servidor; el > solitario es la línea vacía que cierra las cabeceras de solicitud. curl envía tres cabeceras de solicitud; un navegador, más de diez.

• Content-Type: text/html; charset=utf-8: el cuerpo es una página web en texto UTF-8.
• Age: 6679: la red de distribución de contenidos (CDN) que está delante del sitio guarda esta copia desde hace 6.679 segundos, alrededor de 1 hora y 51 minutos.
• cf-cache-status: HIT: no es una cabecera estándar, sino una nota propia de esa red que indica que la copia salió de su caché.
• alt-svc: h3=":443": el sitio también habla HTTP/3 en el puerto 443.

Fíjate en Content-Type junto a last-modified: una sola respuesta, dos maneras de escribir los nombres.

¿Las cabeceras HTTP distinguen entre mayúsculas y minúsculas?#

No, los nombres de las cabeceras no distinguen entre mayúsculas y minúsculas: Content-Type, content-type y CONTENT-TYPE son la misma cabecera. El RFC 9110 lo dice en una línea: «Field names are case-insensitive.» Cuando pedimos la misma página por http:// sin cifrar, el servidor llegó a escribir Last-Modified y Allow con mayúscula inicial.

Los valores siguen las reglas de cada cabecera. text/html y TEXT/HTML designan el mismo tipo de archivo, pero el valor de una cookie o un token de inicio de sesión tiene que volver exactamente como lo envió el servidor.

HTTP/2 y HTTP/3, las versiones más recientes del protocolo, exigen nombres en minúsculas, y por eso las Herramientas para desarrolladores de Chrome muestran content-type. En nuestra prueba, Chromium cargó example.com por HTTP/3, y su solicitud empezaba con :method, :path, :scheme y :authority. Estas pseudocabeceras llevan lo que HTTP/1.1 pone en la primera línea y en la cabecera Host.

En tu código, compara los nombres de las cabeceras sin tener en cuenta mayúsculas ni minúsculas. El objeto Headers de JavaScript y la biblioteca requests de Python ya lo hacen; un diccionario normal, no.

¿Cuáles son las cabeceras de solicitud más comunes?#

Las cabeceras de solicitud describen quién pregunta y qué acepta:

Gracias a Host, un servidor con una sola dirección IP puede alojar muchos sitios web: lee el nombre y elige el sitio correspondiente. Con Accept-Language un sitio elige un idioma antes de que tú elijas uno; los números q son pesos de 0 a 1, así que es-ES,es;q=0.9 significa primero español de España y, en segundo lugar, cualquier variante de español.

Cookie devuelve los pequeños valores que un sitio guardó antes con Set-Cookie, como el ID de una sesión iniciada. ¿Qué son las cookies y para qué sirven? recorre ese intercambio paso a paso.

Authorization lleva credenciales para el propio sitio, a menudo después de una respuesta 401 Unauthorized; el estándar prohíbe que un proxy la modifique. Referer, mal escrita en el estándar, indica la página cuyo enlace te trajo hasta aquí; en un enlace hacia otro sitio, los navegadores envían por defecto solo el origen, como https://example.com/. Chrome también envía cabeceras propias, como sec-ch-ua, una lista breve de marcas y versiones del navegador.

¿Cuáles son las cabeceras de respuesta más comunes?#

Las cabeceras de respuesta le dicen al navegador qué ha recibido y qué debe hacer con ello:

Content-Type decide qué hace el navegador con el cuerpo: mostrar text/html como página, enseñar image/png como imagen, pasar application/json a un script. Un valor equivocado es el motivo por el que una página a veces muestra código en bruto. Content-Disposition: attachment, en cambio, pide al navegador que descargue el archivo.

Cache-Control fija las reglas de caché: max-age=3600 permite reutilizar la copia durante una hora, y no-store prohíbe guardar ninguna copia. Set-Cookie puede aparecer muchas veces en una misma respuesta, una línea por cookie. Location acompaña a las redirecciones (los códigos 3xx) e indica la nueva dirección.

Retry-After acompaña a 503 Service Unavailable y a 429 Too Many Requests e indica cuánto esperar, en segundos o como fecha. Retry-After: 120 significa dos minutos; un cliente bien hecho espera ese tiempo.

¿Cómo ver las cabeceras HTTP en Chrome?#

Chrome muestra todas las cabeceras de cada solicitud en sus Herramientas para desarrolladores (DevTools), en el panel Red. Con los nombres de la interfaz en español:

1. Abre la página y pulsa F12, o Ctrl + Mayús + I en Windows (Cmd + Opción + I en un Mac). También puedes hacer clic derecho en la página y elegir Inspeccionar.
2. Haz clic en la pestaña Red. Las herramientas solo registran mientras están abiertas, así que vuelve a cargar la página.
3. En la columna Nombre, haz clic en la primera fila, que es la propia página.
4. Abre la pestaña Encabezados, que es como Chrome llama a las cabeceras. General muestra la dirección, el método y el código de estado; debajo aparecen Encabezados de respuesta y Encabezados de solicitud.
5. Marca Sin procesar junto a una sección para ver las líneas tal como llegaron, en su orden original.

Si ves el aviso «Se muestran los encabezados provisionales», lo más probable es que el archivo saliera de la caché del navegador; marca Inhabilitar caché en la parte superior del panel y vuelve a cargar. La referencia del panel Red de Chrome explica las demás opciones, como mostrar una cabecera en su propia columna.

Para repetir una solicitud fuera del navegador, haz clic derecho sobre ella y elige Copiar > Copiar como cURL (cmd) en Windows, o Copiar como cURL en un Mac. El comando incluye tus cookies y cualquier cabecera de inicio de sesión, así que nunca lo pegues en un foro ni en un chat públicos.

¿Cómo ver las cabeceras HTTP con curl?#

curl muestra las cabeceras desde la línea de comandos, algo práctico para revisar tu propio sitio. Escribe los comandos en el Símbolo del sistema; en Windows PowerShell, escribe curl.exe, porque ahí curl es el nombre de otro comando.

curl -I https://example.com

-I pide solo las cabeceras de respuesta, mediante una solicitud HEAD; en nuestra prueba imprimió las mismas cabeceras de respuesta que vimos arriba. Otras dos opciones:

• curl -v https://example.com muestra las cabeceras de solicitud, las de respuesta y los detalles de la conexión.
• curl -I -H "Accept-Language: de" https://example.com añade una cabecera tuya, por ejemplo para probar cómo responde tu sitio a un navegador configurado en alemán.

El curl incluido en Windows habla HTTP/1.1 (su salida detallada dice ALPN: curl offers http/1.1), así que ves los nombres tal como los escribió el servidor. Una versión de curl compilada con soporte para HTTP/2 los imprime en minúsculas en los sitios que hablan HTTP/2.

¿Qué cabeceras de seguridad debe enviar un sitio web?#

Las cabeceras de seguridad son cabeceras de respuesta que activan protecciones adicionales del navegador para tu sitio. Se configuran en el servidor web, en la red de distribución de contenidos o en la propia aplicación:

• Strict-Transport-Security (HSTS): usar solo HTTPS en este sitio durante max-age segundos. Los navegadores la ignoran si llega por HTTP sin cifrar. Añade includeSubDomains únicamente cuando todos tus subdominios funcionen con HTTPS.
• Content-Security-Policy (CSP): enumera desde dónde puede cargar la página scripts, estilos e imágenes, lo que limita lo que puede hacer un script inyectado.
• X-Content-Type-Options: nosniff: el navegador confía en Content-Type en lugar de adivinar el tipo de archivo.
• X-Frame-Options, o frame-ancestors en la CSP: si otros sitios pueden mostrar tu página dentro de un marco, una defensa contra el clickjacking (engañar a los visitantes para que hagan clic en una página oculta).
• Referrer-Policy: qué parte de la dirección de tu página va en Referer cuando los visitantes se marchan.

Revisa tu sitio con curl -I o en Encabezados de respuesta en DevTools. En las cookies de inicio de sesión, los atributos Secure, HttpOnly y SameSite dentro de Set-Cookie importan tanto como estas cabeceras.

¿Qué cabeceras añade o lee un proxy?#

Un proxy trabaja con unas pocas cabeceras propias: algunas las lee de tu solicitud y otras puede añadirlas antes de reenviarla.

• Proxy-Authorization lleva al proxy tus datos de acceso, como user:pass; el proxy los usa él mismo en lugar de pasarlos al sitio.
• Proxy-Authenticate llega con la respuesta 407 Proxy Authentication Required del proxy cuando faltan los datos de acceso o son incorrectos.
• Via deja constancia de que un intermediario gestionó el mensaje; el estándar HTTP dice que un proxy debe añadirla.
• X-Forwarded-For y su forma estándar, Forwarded, llevan la dirección IP original del cliente. El RFC 7239, que define Forwarded, dice que un proxy pensado para ofrecer anonimato no la usará.

Que un proxy añada o no Via o X-Forwarded-For es lo que clasifica los proxies en transparentes, anónimos y élite; Proxy transparente, anónimo y élite: ¿qué los diferencia? muestra la misma solicitud en los tres niveles.

Con HTTPS, casi todo esto desaparece. Para una dirección https://, tu app pide al proxy que abra un túnel con CONNECT, y desde ese momento el proxy reenvía bytes cifrados sin leerlos. Ejecutamos curl a través de un pequeño proxy de prueba en nuestro propio equipo, con los datos de acceso de ejemplo user:pass:

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> Proxy-Authorization: Basic dXNlcjpwYXNz
> User-Agent: curl/8.22.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*

El registro del proxy solo recogió el primer bloque. La solicitud GET y sus cabeceras viajaron dentro del túnel cifrado, de modo que el proxy no pudo leerlas ni añadirles líneas. dXNlcjpwYXNz es simplemente user:pass en Base64, una codificación, no un cifrado.

Así transportan tu tráfico los Proxies HTTPS: el gateway de Proxynet retransmite el túnel sin descifrarlo, por lo que no instalas ningún certificado nuestro. Un proxy cambia la dirección IP que ve el sitio; no es motivo para reescribir tus propias cabeceras. No modifiques User-Agent, Referer ni X-Forwarded-For para hacerte pasar por otro navegador u otro visitante; los scripts que ejecutes deben enviar un User-Agent honesto que nombre tu herramienta.

Dónde te encuentras con las cabeceras HTTP#

• Versiones por idioma: un sitio lee Accept-Language para elegir la primera página que ves.
• Inicio de sesión: la cabecera Cookie lleva tu sesión en cada solicitud.
• API: un token en Authorization, Content-Type: application/json para el cuerpo.
• Caché: Cache-Control y Age deciden si una copia guardada sigue vigente.
• Descargas: Content-Disposition decide si un archivo se abre o se guarda.

Errores frecuentes#

• Leer los nombres de las cabeceras distinguiendo mayúsculas y minúsculas en el código. headers["Content-Type"] en un diccionario normal no encuentra el content-type que manda un servidor HTTP/2.
• Compartir un comando «Copiar como cURL». Lleva tus cookies, así que cualquiera que lo tenga puede actuar como si fuera tú.
• Fiarte de un X-Forwarded-For que llega de internet. Un cliente puede enviar cualquier valor; solo son fiables las entradas que añadió tu propio proxy o tu balanceador de carga (el servidor que reparte el tráfico entre tus servidores).
• Activar HSTS con includeSubDomains demasiado pronto. Un subdominio sin HTTPS queda inaccesible para los visitantes que ya vieron la cabecera.
• Dejar que se acumulen las cookies. Las cookies grandes llevan la solicitud por encima del límite de cabeceras del servidor, y el sitio responde 400 o 431.

Guía de decisión#

Preguntas frecuentes#

¿Qué es la cabecera User-Agent?#

Es la cabecera de solicitud que nombra el navegador o el programa que hace la solicitud, con su versión y normalmente el sistema operativo; curl envía curl/8.22.0. Los sitios la usan para sus estadísticas y para adaptarse a las rarezas de cada navegador. ¿Qué es el User-Agent? Cómo verlo y cambiarlo muestra cómo leer el tuyo.

¿Qué significa X-Forwarded-For?#

Es una cabecera en la que un proxy o un balanceador de carga escribe la dirección IP del cliente que le envió la solicitud, para que el servidor que está detrás vea la dirección del visitante. Nunca se estandarizó formalmente; Forwarded (RFC 7239) es la versión estándar. Cualquiera puede enviarla, así que un servidor solo debe fiarse de las entradas que añadió su propio proxy.

¿Las cabeceras HTTP se cifran con HTTPS?#

Sí. Con HTTPS, las cabeceras viajan dentro del cifrado junto con el cuerpo, así que las redes y los proxies del camino no pueden leerlas. La dirección IP del servidor sigue siendo visible y, en la mayoría de los casos, también el nombre de dominio, que se envía mientras se establece la conexión.

¿Qué son las cabeceras HTTP en una API?#

Son las mismas cabeceras, usadas de forma más deliberada. Una llamada a una API suele enviar una clave o un token en Authorization (algunas API usan una cabecera propia, como X-API-Key), declara el cuerpo con Content-Type: application/json y pide JSON con Accept. Cuando se envían demasiadas solicitudes, la respuesta suele ser un 429 con Retry-After.

¿Qué significa «HTTP header is larger than 8192 bytes»?#

Significa que una solicitud o una respuesta llevaba más datos de cabecera de los que acepta el software que la procesa. El mensaje procede de Netty, una biblioteca de red para Java con un límite predeterminado de 8.192 bytes; otras cifras, como 10.240, son límites configurados a propósito. HTTP en sí no fija ningún máximo. Si eres visitante, borra las cookies de ese sitio; si eres desarrollador, reduce las cookies o los tokens, o sube el límite.

¿Por qué la cabecera Referer está mal escrita?#

Porque el nombre con la errata ya figuraba en la especificación de HTTP/1.0 de 1996, y el software de todo el mundo lee la cabecera con ese nombre. El estándar actual conserva Referer con una nota «[sic]»; la cabecera más reciente, Referrer-Policy, sí está bien escrita.

En resumen#

Las cabeceras HTTP son las líneas Nombre: valor del principio de cada solicitud y de cada respuesta. Las cabeceras de solicitud indican el sitio, el navegador, los idiomas, las cookies y las credenciales; las de respuesta dicen qué es el cuerpo, cuánto tiempo guardarlo en caché, qué cookies almacenar y adónde ir después. Los nombres no distinguen entre mayúsculas y minúsculas, y HTTP/2 y HTTP/3 los escriben en minúsculas. Léelas en DevTools o con curl, y envía cabeceras de seguridad desde tu propio sitio. Con HTTPS, un proxy solo ve la breve solicitud CONNECT con el nombre del sitio y tus datos de acceso al proxy; para enviar tu propio tráfico a través de uno, empieza por nuestros servicios de proxy.