What Are My HTTP Request Headers?
The headers your browser sent with this very request, shown back to you the moment the page loads — rendered for this request only, and kept nowhere.
Want the connection behind the envelope? See your full IP report
Your request headers
Your own request’s headers, as RahaKit’s Worker received them when this page was loaded.
This page shows the request headers your browser sends. It does not fetch or show another site’s response headers.
11 header fields reached RahaKit's Worker with this request.
6 of them were added or changed on the way. Observed: 9 Nov 2026 · 07:21 UTC.
Requesting software Parsed from User-Agent
Read from the request’s own description of itself — software can shorten or change that description, so treat this as reported, not verified.
Privacy signals
Do Not Track: not sent · Global Privacy Control: not sentSignals are requests a site may honour or ignore — not guarantees.
Your browser sent these
The fields your own browser or app supplied with this request, each with a plain-words explanation.
Added on the way
Fields your browser did not write — Cloudflare and other infrastructure added or rewrote them in transit.
Not sent this time — that is normal
- Client Hints — your browser did not send them. Chromium sends a basic set by itself; Firefox and Safari do not send this set at all. Both are normal.
- Referer — nothing led here, or your browser chose not to say. A typed address, a bookmark and many privacy settings all produce exactly this.
- Fetch Metadata — older browsers and non-browser clients do not send it.
Copies are made only from the safe values already shown on this page — credential values are never included. Review a copy before sharing it: it can contain your public IP address and browser details.
Raw view — the same values, without explanations
User-Agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
Accept: */*
Accept-Encoding: gzip, deflate, br
Host: rahakit.com
Connection: Keep-Alive
CF-Connecting-IP: 216.73.217.110
CF-IPCountry: US
CF-Ray: a57b0f534a06452a
CF-Visitor: {"scheme":"https"}
X-Forwarded-Proto: https
X-Real-Ip: 216.73.217.110
Accept-Encoding (as received): gzip, br
Authorization: [not sent with this request]
Proxy-Authorization: [not sent with this request]
Cookie: [not sent with this request]
What these headers mean
A plain-language guide to the headers you are most likely to see above — one line each.
How websites use these headers
Websites read these headers to serve you well and to run at all. Accept and Accept-Language drive content negotiation — the server picks a format and a language you can actually use. User-Agent and the Client Hints help a site understand which browser it is talking to, so it can avoid features your browser lacks. The Sec-Fetch-* headers let a server check whether a request really came from its own pages. And the connection metadata Cloudflare adds tells the site where the request arrived from.
The same list can also be combined into a fingerprint. No single header names you, but the exact combination — browser build, platform, languages, accepted formats — is shared by fewer and fewer people as you add fields, and sites can use it to recognise a browser across visits without any cookie. Seeing your own list here, in full, is the honest way to understand what every site you visit receives.
What this viewer cannot show
- It shows only the request that loaded this page. It cannot inspect another website, another tab’s requests, or a request you made earlier.
- It cannot show any site’s response headers — that is a different question, about what a server sends back, and this page only ever looks at your own request coming in.
- Header names may appear lowercased or in a different order than your browser sent them; servers and intermediaries are allowed to normalise both.
- The list can include entries added in transit — by Cloudflare, marked above — and possibly by your own network or security software, which this page cannot distinguish.
- Credential values are removed before rendering and cannot be shown: Authorization, Proxy-Authorization and cookies.
Privacy and data handling
This page is rendered for your request, once. The Worker reads the headers that arrived with this page load, writes them into the page you are reading, and RahaKit keeps no record of them — no storage, no logs, and nothing sent to any outside lookup service. The page is delivered through Cloudflare’s network, which processes every request on the way; that is where the cf-* fields come from. The credential-redaction rule is applied before rendering: Authorization, Proxy-Authorization and cookie values never become page content. Reloading the page simply renders your new request the same way.
Request headers vs response headers
Every exchange between your browser and a website has two sets of headers. Request headers travel with your request: they describe the requesting software, the formats and languages it accepts, and the context of the request. Response headers travel back with the website’s answer: they describe the content itself, its caching rules and the site’s security policies.
This viewer shows only the first kind — the request that loaded this page. It never fetches another website, so it cannot show you any site’s response headers. The next section shows how to see both kinds for any page, using your own browser.
How to view headers in your browser
Your browser’s developer tools show the headers of every request a page makes — including the response headers this viewer cannot see. In Chrome, Edge and Firefox the steps are the same:
- Open the page you want to inspect, then open Developer Tools (F12, or Ctrl+Shift+I).
- Choose the Network tab and reload the page.
- Click the first request in the list — the page itself — and open its Headers panel.
- Request Headers are what the browser sent; Response Headers are what the site sent back.
In Safari, first enable the Develop menu (Settings → Advanced → “Show features for web developers”), then use the Network tab the same way. What you see there can differ slightly from this page: your tools show the request as your browser built it, while this page shows the request as it arrived at RahaKit, after Cloudflare’s handling on the way.
Frequently asked questions
What is an HTTP request header?
A header is a labelled line of metadata your browser attaches to every request: who it is, what it can accept, how the request was made. The server reads them before deciding what to send back. This page shows you the exact set that arrived with this page load.
What does my User-Agent say about me?
It names your browser family and version, its rendering engine and your operating system — for example, that you run a Chromium browser on Windows. It does not contain your name or identity, and browsers can change or reduce it; treat it as a browser’s self-description, not a fact about you.
Why is my Accept-Language set that way?
Your browser builds it from your language settings: your first-choice language at full weight, then fallbacks with lower weights, such as en-US followed by en;q=0.9. Sites use it to offer you a language. Changing your browser’s language order changes this header on the next request.
What are Client Hints?
Client Hints are the Sec-Ch-Ua headers: a newer, structured way for Chromium-based browsers to state brand, version, platform and mobile-ness, instead of packing everything into the User-Agent string. Browsers that are not Chromium-based generally do not send them, so their absence here is normal.
Why are some headers marked “likely added by Cloudflare”?
This page sits behind Cloudflare, which adds its own metadata headers (names like cf-*) as your request passes through. The marker is a judgement from the header’s name pattern, so it says likely rather than certain: a name can match the pattern without Cloudflare having added that particular entry.
Why is a header I expected not here?
Headers are optional unless the protocol requires them. Browsers send different sets depending on how the page was opened, the browser family and your settings: a typed address sends no Referer, non-Chromium browsers send no Client Hints, and privacy tools strip more. The viewer renders only what actually arrived.
Can these headers identify me personally?
Not directly: headers do not reveal your name, street address, phone number or email. They describe your browser and request, not you. In combination they can narrow a browser down — the fingerprinting point in the guide above — but there is no identity field in the list.
Are my headers stored or logged?
No. They are rendered into this page for this request and kept nowhere by RahaKit: no storage, no logs, and nothing sent to any outside service. The page is delivered through Cloudflare’s network, which processes the request on the way. The credential-bearing ones are removed before rendering, so they never appear even in your own copy of the page.
What is the difference between request headers and response headers?
Request headers travel with your request to a site — they describe your browser, your preferences and the request itself. Response headers travel back with the site’s answer — they describe the content, its caching rules and the site’s security policies. This page shows only request headers: the ones your own request carried.
Why can the Accept-Encoding here differ from what my browser sent?
Because Cloudflare can rewrite it on the way in. The value your browser originally offered is kept separately in Cloudflare’s connection data, so this page shows your browser’s original in the main list and marks the rewritten value under “Added on the way”.
What is Sec-GPC — and is it the same as Do Not Track?
Sec-GPC carries the Global Privacy Control signal: your browser saying you do not want your data sold or shared. Do Not Track (DNT) is its older relative, now largely deprecated and widely ignored. Both are requests, not guarantees — each site chooses whether to honour them. The summary above the header list shows whether either signal arrived with your request.
Can these headers prove I am using a VPN or a proxy?
No. Forwarding fields can show that a request passed through some intermediary, but they cannot prove a VPN, a proxy or Tor: CDNs, work networks and privacy tools all leave similar traces, and their absence proves nothing either. This page shows the fields and explains them; it does not draw that conclusion.
Can I see another website’s response headers here?
No. This viewer renders only the request that loaded this page. To inspect another site’s response headers, open that site in your browser and use the Network tab of its developer tools, as described above.
Back to the whole picture: See your full IP report — your addresses, location, network and connection, in one place.
How fast is the connection behind them? Run the internet speed test — download, upload, ping and jitter, measured the same honest way.