HTTP Headers Explained: What Every Site Knows About You Before You Click

Every time you load a webpage, your browser sends a little envelope of information ahead of the actual request. Not the URL. Not your form data. Not the cookies (well, also those). Something else entirely. A list of about 15 to 30 little name and value pairs called HTTP headers.

You did not write them. You did not consent to them. They just go out, every single request, and they tell the server on the other side a surprising amount about you. Your browser, your operating system, your language, where you came from, what you can decode, even some hardware hints. All in plain text. All before the page even starts loading.

And the server sends its own pile of headers back, telling your browser things like "this connection must be encrypted forever" or "you are not allowed to put this in an iframe" or "here is a tracking cookie that lasts two years."

This is a tour of what HTTP headers actually are, what every common one means, what they leak about you, and what every site should be sending in 2026.

The Basic Mechanic

HTTP is a request and response protocol. Your browser sends a request to a server, the server sends back a response. Both sides include headers along with their main content.

A request looks like this in the raw:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,*/*
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br

That is your browser saying "Hey example.com, give me the homepage. Here is what I can handle. Here is what I prefer. Here is who I am."

The server responds:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 8472
Strict-Transport-Security: max-age=31536000; includeSubDomains
Set-Cookie: session=abc123; Secure; HttpOnly

That is the server saying "Got it. Here is HTML, 8472 bytes long. Your connection must stay HTTPS for the next year. Also here is a session cookie that JavaScript cannot read."

Each line is a header. Name on the left, value on the right, separated by a colon. They are case-insensitive (so User-Agent and user-agent are equivalent). HTTP/2 and HTTP/3 actually require lowercase headers and add a few special pseudo-headers like :method and :status, but the concept is identical.

What Your Browser Tells Every Site

Some of these you probably knew about. Some are going to surprise you.

User-Agent

The classic. A long string identifying your browser, version, OS, and rendering engine. Mine right now looks like:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

That tells any server I am running Chrome 128 on macOS Big Sur. From a privacy perspective this is fingerprinting fuel. Combine the User-Agent with a few other headers and you can identify a specific person across visits even without cookies.

In Chrome 128 and later, the full User-Agent has been deprecated and replaced (more on that in a second).

Accept-Language

What languages you prefer for content. Mine says en-US,en;q=0.9,fr;q=0.8. That means I prefer American English, then any English, then French as a third choice. The q= numbers are quality factors from 0 to 1.

This header was originally meant to help servers serve translated content. In practice it is one of the strongest fingerprinting signals because language preferences are surprisingly unique per person. It also leaks your rough location since most people configure their browser language to match their country.

Accept-Encoding

What compression formats your browser can decode. Usually gzip, deflate, br. The br stands for Brotli, a Google-developed compression that works better than gzip for most text. If you see zstd in there, that is the new Zstandard format some browsers added in 2024.

This is a minor fingerprint. Some browsers support different combinations.

Referer

Yes, it is misspelled. That is a famous typo from the original 1996 RFC that nobody ever fixed. The Referer header tells the new site which page you came from.

Click a link from Google search to a blog post? Google's full search URL gets sent in the Referer. The blog now knows what you searched for.

This is why most sites use Referrer-Policy (correctly spelled) to control how much of the referrer leaks. Common values are no-referrer, same-origin, and strict-origin-when-cross-origin (the modern default).

Cookie

Anything the server previously stored in your browser via Set-Cookie. Sessions, login state, tracking IDs, ad targeting, the works. This is the most well known privacy concern by far. Cookies follow you around like a name tag.

Sec-CH-UA Client Hints

The new replacement for User-Agent. Instead of one giant string with everything, modern Chrome sends little focused hints:

Sec-CH-UA: "Chromium";v="128", "Not?A_Brand";v="24", "Google Chrome";v="128"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "macOS"

The browser only sends low-entropy hints by default. The site has to actively request more detail (like full OS version) using an Accept-CH response header. Browsers can refuse those requests, especially in Incognito mode.

The privacy theory: User-Agent gave away too much by default. Client Hints make sites ask before they get the juicy details. The cynical theory: it is now harder to know what users are running, but the data is still very accessible if you ask for it.

DNT (Do Not Track)

DNT: 1 means the user has opted out of tracking. Set in browser settings.

It is also completely ignored by basically every commercial site on the internet. Was ratified as a W3C draft, never finalized, never enforced. Some sites pretend to respect it. Most do not even check.

Apple removed DNT from Safari years ago because they decided it was actually a fingerprinting vector (people who turned it on were rare and identifiable). Firefox still has it but with a clear "this might do nothing" disclaimer.

Sec-Fetch-* Headers

Modern set of metadata about why a request is happening:

• Sec-Fetch-Dest: document means this is the main page load
• Sec-Fetch-Mode: navigate means user typed a URL or clicked a link
• Sec-Fetch-Site: cross-site means this came from a different origin

These help servers do smarter security. A request with Sec-Fetch-Site: same-origin is probably legitimate. One with cross-site and a sensitive endpoint could be CSRF. Servers can use these to block obvious abuse.

The Fingerprinting Problem

You can identify a unique browser instance just from the combination of headers it sends. Without cookies. Without fingerprinting JavaScript. Just the raw headers.

A 2010 EFF study called Panopticlick showed that combining User-Agent, Accept-Language, Accept-Encoding, and a few other passive signals creates a unique fingerprint for over 99% of users. That study was 15 years ago. The math has only gotten more precise.

This is one reason the browser industry started moving toward Client Hints, User-Agent reduction, and stricter referrer policies. The old assumption that headers were "just metadata" turned out to be a privacy nightmare.

The solution is not really fixable from the user side. You can install browser extensions that randomize headers, but randomization itself is unique. You can use Tor Browser, which sends identical headers as everyone else using Tor. For everyone else, you are mostly stuck with the level of fingerprintability your browser was shipped with.

If you want to see exactly what headers your current browser sends, check our free HTTP headers viewer at whatismyip.technology/tools/http-headers. It echoes back everything your browser sent in the request.

What Servers Send Back

The other half of the conversation. Response headers control how your browser behaves.

Content-Type

What the response actually is. Common values:

• text/html; charset=UTF-8 for normal web pages
• application/json for API responses
• image/webp for modern image formats
• text/css for stylesheets

If a site sends the wrong Content-Type, browsers can guess (called MIME sniffing), but that is also a security risk because attackers can sometimes upload "images" that browsers decide are JavaScript.

Strict-Transport-Security (HSTS)

Forces HTTPS for future visits. A header like max-age=31536000; includeSubDomains; preload tells your browser:

• Always use HTTPS for this domain for the next year
• Apply this rule to every subdomain too
• This site is on the HSTS preload list, so even the first visit must be HTTPS

Once a site sets HSTS, your browser remembers and refuses HTTP for the duration. Even if a user types http://, the browser auto-upgrades to https://.

This single header has done more for web security than almost any other in the last decade. It blocks an entire class of downgrade attacks.

Content-Security-Policy (CSP)

The most powerful and most ignored security header. CSP tells the browser what content sources to allow. A simple example:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com

That means: only load resources from this same origin, and JavaScript can additionally come from cdn.example.com. Anything else gets blocked.

CSP is amazing for stopping XSS attacks. If an attacker manages to inject a script tag pointing to evil.com, CSP will block it before it loads.

The downside: CSP is hard to configure correctly, especially for sites that already use a lot of third-party scripts. Most sites either skip it or set it to something so permissive it might as well not be there.

X-Frame-Options

Stops your site from being embedded in an iframe by other sites. X-Frame-Options: DENY blocks all iframe embedding. SAMEORIGIN allows your own site to embed itself.

Why does this matter? Clickjacking attacks. An attacker embeds your bank in a transparent iframe over a fake button. User clicks "Win a prize," but they actually clicked "Transfer $1000" on the bank in the iframe. X-Frame-Options prevents that.

CSP has a frame-ancestors directive that does the same thing better, but X-Frame-Options is still set everywhere because legacy browsers do not support CSP.

X-Content-Type-Options

X-Content-Type-Options: nosniff tells the browser not to MIME-sniff. Use the Content-Type the server sent, do not guess. This blocks attacks where a malicious "image" gets executed as JavaScript.

Set this everywhere. There is no downside.

Permissions-Policy

A fine grained control over what browser features a page can use. Want to disable the camera and microphone for your entire site?

Permissions-Policy: camera=(), microphone=(), geolocation=()

This is useful both for security (third-party scripts on your page cannot suddenly request camera access) and for performance (you can disable features you do not need).

Set-Cookie

Sets a cookie. Modern best practice always includes flags:

Set-Cookie: session=xyz; Secure; HttpOnly; SameSite=Strict

• Secure means the cookie only sends over HTTPS
• HttpOnly means JavaScript cannot read it (blocks XSS theft)
• SameSite=Strict means the cookie does not get sent on cross-site requests (blocks CSRF)

A cookie without these flags in 2026 is basically a security bug.

CORS Headers

Cross-Origin Resource Sharing. Determines which other origins can call your API from JavaScript. Without CORS headers, browsers block cross-origin fetches by default.

Access-Control-Allow-Origin: * means anyone can call your API. That is what we set on whatismyip.codes so developers can call our API from any web app.

Access-Control-Allow-Origin: https://yourapp.com means only your specific app can call this API. That is what most company APIs set.

What CDNs and Cloud Providers Add Without Asking

If your site sits behind Cloudflare, Vercel, AWS, or any major CDN, those services add their own headers to responses. Most of the time without you knowing.

Cloudflare adds CF-Ray (a unique request ID) and CF-Cache-Status (whether the response came from cache). The CF-Ray value contains the data center code. 8a2b3c4d5e6f7g-ORD was served from Chicago.

Vercel adds X-Vercel-Cache, X-Vercel-Id, and Server: Vercel. The X-Vercel-Id reveals which edge region handled the request.

AWS adds X-Amz-Cf-Id for CloudFront and X-Cache: Hit from cloudfront for cache status.

These are useful for debugging. They are also subtle infrastructure leaks. If a security researcher sees Server: Vercel in your response, they know exactly what your hosting stack is. Most security teams just leave them on because the debugging value beats the marginal info disclosure.

You can strip these headers via configuration if you really want to. For example, Vercel lets you remove the Server header in vercel.json. Cloudflare has rules to strip CF-Ray. Whether it is worth the trouble depends on your threat model.

What Every Site Should Send in 2026

If you run any kind of web service, this is the minimum security header set you should be returning. OWASP and Mozilla both recommend this baseline.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

You can add more. You probably should add CSP rules tailored to your site. But these six headers cover most of the basic web vulnerabilities and they cost nothing to set.

The X-XSS-Protection header is now considered deprecated. CSP does the same job better. If you have it set, removing it is fine.

Debugging Your Headers

To see what your own site is sending:

curl -I https://yoursite.com

-I means HEAD request. The response is just the status line and headers, no body.

For more detail (HTTP/2 view):

curl -sI -o /dev/null -D - --http2 https://yoursite.com

Browser DevTools work too. Open the Network tab, reload the page, click any request, look at the Headers tab. Both Request and Response headers are there. HTTP/2 connections show pseudo-headers prefixed with colons.

Online tools like securityheaders.com will scan your site and grade your security headers. Useful for a quick audit. Run yours through it and see what is missing.

To inspect headers your browser is sending right now, our HTTP Headers tool at whatismyip.technology/tools/http-headers shows you the live request data. Compare it to what you expect, especially after VPN or proxy changes.

How Headers and Your IP Are Connected

HTTP headers do not include your IP address directly. Your IP gets seen by the server at the TCP level, before any HTTP exchange happens. But headers can reveal IP-adjacent information.

X-Forwarded-For and X-Real-IP are headers that proxies and load balancers add to forward the original client IP to the backend server. If you are behind Cloudflare, the backend sees Cloudflare's IPs as the source, but the CF-Connecting-IP header tells the backend your real IP.

This is why a VPN leak check needs to consider not just the obvious IP but also what gets sent in headers. WebRTC, browser extensions, and JavaScript APIs can all expose your real IP even when your VPN is forwarding traffic correctly.

For a deeper look at what your IP exposes about you (and what your headers add on top), see what your IP address reveals and the DNS leak guide.

The Compression Layer

HTTP/2 introduced HPACK header compression. HTTP/3 added QPACK, which is similar but designed to work with multiplexed streams over QUIC.

The basic idea: most headers repeat across requests. User-Agent is identical for every page on your browsing session. Accept-Encoding does not change. So instead of sending these big strings every time, the protocol indexes common values into a table and sends a tiny ID instead.

You usually do not have to think about this. Browsers and servers handle it automatically. But it does mean you cannot just look at packet captures and read raw headers anymore. They are compressed at the wire level. DevTools shows the decompressed view by default.

Practical Takeaways

If you are building a site:

• Set the six recommended security headers
• Use modern cookie flags (Secure, HttpOnly, SameSite)
• Configure CSP even if it is just default-src 'self'
• Test with securityheaders.com or similar
• Remove unnecessary version disclosure if your threat model demands it

If you are debugging a site:

• curl -I is your fastest tool for header inspection
• DevTools Network tab shows the full picture including HTTP/2 pseudo-headers
• Look for Set-Cookie flags before assuming your auth is secure
• Watch for unexpected X- prefixed headers from CDNs

If you are just curious:

• Your browser is leaking more than you think on every request
• Most of it is benign, some of it is fingerprinting fuel
• Modern browsers are slowly reducing what gets shared by default
• The HTTP headers tool on whatismyip.technology shows you exactly what is happening

The web works on these little name-value pairs flying back and forth. Most of the time you never see them. But they are running everything, every site, every request, all the time.

Now you know what they are doing.