~/tools/headers

> http headers

inspect the http request headers your browser sends to drwho.me: user-agent, accept, accept-language, cookie (if any), and more. read-only — no credentials collected.

$ request headers

## overview

every http request carries a set of headers: key-value metadata that tells the server what the client wants and can accept. browsers set most of them automatically — user-agent, accept, accept-language, accept-encoding, connection, and so on. servers, reverse proxies, and cdns add their own en route (cf-ray, x-vercel-id, etc.). this tool shows the headers that arrived at drwho.me with your request. it is read-only: we read what vercel's edge observed and render it back. useful for: debugging cors failures, verifying an api gateway's routing, inspecting what locale your browser advertises, seeing what a bot sends, or checking your cdn's request fingerprint. sensitive values (cookie, authorization) are shown only if your browser sent them — and they are not stored.

## how to use

load the page — everything renders on load. no input needed.
scan the list — headers are listed alphabetically by name.
look for custom headers — your proxy, firewall, or extension may inject custom headers (starting with x-). they will appear if forwarded.
reload to refresh — if you change something (disable an extension, switch browser), reload to see updated headers.

## examples

$ example 1 — typical desktop browser

$ in
(chrome on macos)

# out
user-agent: mozilla/5.0 …
accept: text/html,…
accept-language: en-us,en;q=0.9
sec-ch-ua: "chromium";v="131", …

$ example 2 — minimal — curl sends very few headers

$ in
(curl)

# out
user-agent: curl/8.4.0
accept: */*
host: drwho.me

$ example 3 — headers accumulate through proxies

$ in
(behind a corporate proxy)

# out
adds x-forwarded-for, via, x-corp-trace-id, etc.

## common mistakes

cookies — the cookie header only appears if your browser has cookies for this domain. drwho.me sets none itself, so this will usually be empty.
client hints — modern browsers send reduced ua plus sec-ch-ua* client hints. the main user-agent value is intentionally coarse.
proxy headers — x-forwarded-for, x-real-ip, via are added by intermediaries. they may contain your real ip chain.
host header — the host header identifies which domain you are addressing. it determines routing for multi-tenant setups.
order not guaranteed — http does not define header ordering. tools may display them sorted; servers may receive them in any order.

## faq

does this store my headers?

no. we read them from the request and render them back.

where does the sec-ch-ua header come from?

modern chromium-based browsers emit it as part of user-agent client hints, alongside a reduced user-agent.

my authorization header isn't showing — why?

browsers do not automatically send authorization headers to cross-origin sites unless you add them explicitly in code. this is a plain navigation, so no auth.

what is accept-encoding for?

it tells the server which compression methods you support (gzip, br, deflate, zstd). the server uses the best one.

why do i see cf-* headers?

cloudflare's edge adds those when you pass through cloudflare. similar for x-vercel-id on vercel, x-akamai-* on akamai.

can i test with custom headers?

not from this page. use `curl -H "x-custom: value"` or a tool like postman to craft requests.

does my isp see these?

https encrypts headers between your browser and drwho.me, so your isp sees only the hostname (via sni) and traffic volume.

## related tools

user agent — parse your browser's user agent string (browser, os, device, engine).
what is my ip — your public ip address, location, and timezone.

## references

ad slot · tool-headers