The invisible packet that travels with every web request
Every time you open a webpage, your browser doesn't just ask for the HTML. It sends a packet of metadata alongside the request — and the server sends one back with its response. Neither you nor most website visitors ever see these packets. They're called HTTP headers.
Headers are key-value pairs: a name and a value, separated by a colon. They communicate intent, capability, identity, and preference between client and server. Without them, the web as we know it wouldn't function — no compression, no caching, no authentication, no content negotiation.
This guide covers what HTTP headers are, how they work, which ones matter most, and — because this is something most guides skip — what your own headers reveal about your browser and system.
How HTTP headers work
HTTP (HyperText Transfer Protocol) is a request-response protocol. Your browser sends a request to a server; the server sends back a response. Both the request and the response carry headers.
Request headers are sent by your browser. They tell the server: - What type of content you'll accept - What languages you prefer - Who you are (browser, OS, version) - Whether you have a cached copy already - How you'd like the connection handled
Response headers are sent by the server. They tell your browser: - What type of content is being returned - How long to cache it - What security policies apply - Whether the server supports compression - How to handle cookies
A typical HTTP exchange looks like this:
``` GET /my-headers HTTP/2 Host: myipco.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)... Accept: text/html,application/xhtml+xml... Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br ```
The server reads those headers, processes the request, and responds with its own set of headers followed by the page content.
The most important request headers
These are the headers your browser sends with nearly every request:
User-Agent The most well-known header. Contains your browser name, version, operating system, and architecture. Example: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36`.
This single header can narrow you to a specific browser release on a specific OS family — enough to fingerprint you to a small subset of users globally.
Accept-Language Your preferred languages in priority order. Example: `en-US,en;q=0.9,es;q=0.8`. Reveals your likely nationality and native language. Sites use this for automatic localization.
Accept-Encoding Tells the server which compression formats your browser supports. Modern browsers send `gzip, deflate, br, zstd`. The server uses this to compress responses, dramatically reducing page load time — typically 60–80% smaller files.
Accept Declares what content types your browser can handle: HTML, images, JSON, and so on. Rarely varies between users.
Referer (yes, misspelled in the spec) The URL of the page you came from. If you click a link on example.com to visit myipco.com, the request includes `Referer: https://example.com`. This is how analytics tools track where traffic comes from. Browsers now suppress this header in many cross-site scenarios for privacy.
Cookie If a site has previously set cookies on your browser, they're sent back with every subsequent request to that domain. This is how login sessions, shopping carts, and tracking pixels persist across page loads.
Sec-CH-UA (Client Hints) A newer set of headers introduced by Chromium-based browsers. More precise than User-Agent — they report the brand, version, and platform separately. Safari refuses to send them on privacy grounds. Firefox support is limited. If you're on Chrome or Edge, you're sending these.
Security headers: the response side that protects you
Response headers are equally important, especially for security. These are the ones set by the server that protect users:
Strict-Transport-Security (HSTS) Instructs your browser to only connect to this domain over HTTPS — never HTTP — for a set period. Example: `Strict-Transport-Security: max-age=31536000; includeSubDomains`. Once received, your browser enforces this locally, protecting against SSL stripping attacks even before the server responds.
Content-Security-Policy (CSP) One of the most powerful security headers. Defines which scripts, styles, images, and connections a page is allowed to load. A strict CSP dramatically limits cross-site scripting (XSS) attack surface.
X-Content-Type-Options `X-Content-Type-Options: nosniff` prevents browsers from guessing the MIME type of a response. Without it, a browser might execute a JavaScript file that was served as plain text — a vector for MIME-type confusion attacks.
X-Frame-Options / frame-ancestors Controls whether your page can be embedded in an `<iframe>`. Prevents clickjacking — attacks where your page is overlaid inside a malicious site to trick users into clicking things invisibly.
Permissions-Policy Controls which browser APIs a page can use: camera, microphone, geolocation, payment, and more. An important privacy control as sites request more native device capabilities.
Cache-Control Tells browsers and intermediaries how long to cache a response. `Cache-Control: no-store` forces a fresh request every time (useful for sensitive data like banking dashboards). `Cache-Control: max-age=31536000, immutable` caches static assets like fonts or images for a full year.
What your headers reveal about you
This is the part most HTTP headers explainers leave out.
The headers your browser sends are not just technical plumbing — they're a fingerprint. Combined, they reveal:
- Your browser name and version (User-Agent) - Your operating system and architecture (User-Agent, Sec-CH-UA-Platform) - Your preferred languages — which correlates strongly with country and native language (Accept-Language) - Your referral source — which site or search query sent you here (Referer) - Whether you've visited before — via cookies (Cookie) - Whether you're using a proxy or VPN — by the presence or absence of headers like X-Forwarded-For
Some of this is by design (Accept-Language powers localization). Some of it is an unfortunate side effect of how the protocol evolved (User-Agent was intended to help sites serve compatible content; it became the primary fingerprinting vector).
You can see the exact headers your browser is sending right now — with plain-English explanations of what each one reveals — using the live tool at myipco.com: See your HTTP headers live →
No data is logged. The headers are fetched server-side, returned to your browser, and displayed instantly.
HTTP/2 and HTTP/3: do headers change?
The header fields themselves — the names and values — are the same across HTTP versions. What changed is how they're transmitted.
HTTP/1.1 sends headers as plain text, repeated in full on every request. If you load a page with 50 resources, the 50–200 bytes of `User-Agent` gets sent 50 times.
HTTP/2 introduced HPACK compression for headers — a shared table between client and server that encodes repeated headers as small integer references. This dramatically reduces overhead for subsequent requests to the same server.
HTTP/3 (built on QUIC instead of TCP) uses QPACK, a similar approach adapted for out-of-order packet delivery. The efficiency gains compound on slow or lossy connections — mobile networks, satellite links.
For developers: the visible semantics are unchanged. For performance: HTTP/2+ is a significant win, and most modern servers and CDNs default to it.
Frequently asked questions
Can I see the HTTP headers a website is sending to me? Yes. Open your browser's developer tools (F12 → Network tab), reload the page, click any request, and look at the Headers section. You'll see both the request headers your browser sent and the response headers the server returned.
Are HTTP headers encrypted? In HTTPS connections (HTTP over TLS), the headers are encrypted — meaning an observer on the network cannot read your `Cookie` or `Authorization` headers. However, the hostname (the domain you're connecting to) is visible during the TLS handshake unless you're using Encrypted Client Hello (ECH), a newer protocol extension.
What is the X-Forwarded-For header? When a request passes through a proxy or load balancer, the intermediary often appends `X-Forwarded-For: <original-ip>` to tell the destination server who the real client is. If you're using a VPN, your VPN provider's IP appears as the connecting IP, and some VPN setups strip or modify X-Forwarded-For to prevent leaking your real address.
Can websites track me through headers even in private/incognito mode? Yes. Headers like User-Agent, Accept-Language, and Accept-Encoding are the same in private mode as in regular browsing — your browser doesn't change them. The primary thing private mode does is prevent local storage (cookies, history, localStorage) from persisting after the session ends. Your fingerprint via headers remains identical.
**What does "Accept: */*" mean?** It means the browser will accept any content type. Many programmatic clients (fetch calls, curl) send this when they don't have a strong preference. A full browser typically sends a more specific `Accept` list that includes HTML, XHTML, and image types.