Inspect HTTP headers
Enter a URL and read the full set of headers its server sent back: content type, caching rules, cookies and server identity, exactly as received. Compare two snapshots to spot what a release changed. You pay per check, with no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
The body of a response only tells half the story; the headers tell you what server answered, what it cached, what cookies it set and what it silently redirected through.
What the headers say that the page does not
The visible page only tells half the story. The headers that travel with it say which server answered, what it was allowed to cache, which cookies it set and which content type it declared. They carry this information alongside the content without touching it, which is why a header can reveal a change even when the page looks identical. A caching rule that quietly reverted, a server banner that shows software you did not mean to expose, or a cookie flag dropped during a release never appears when you simply look at the rendered page.
When a header check pays off
Browser developer tools show headers well for one page at a time, but they become tedious for a list of pages or for a check you repeat every week. Take a snapshot before and after a release to catch a caching directive or content type that changed. When a proxy or a content delivery network sits in front of your site, read the server and cache status headers to see which layer actually answered instead of guessing from its behavior. And confirm that session cookies carry the flags you expect in every environment, not only in the one you happened to open in your browser.
The problem with checking headers by hand
Browser developer tools show headers beautifully for one page at a time, but they do not scale to a list of a hundred URLs, and they cannot run inside a CI pipeline or a nightly job. Anyone who has copy-pasted curl -I output into a spreadsheet knows the pain: it works until you need to do it again next week, or for every page on a site instead of just one.
What to actually look for
Watch for headers that should be stable across deploys — content type, caching policy, server identity — changing unexpectedly, and for headers that should exist but are simply missing, since an absent header is often as telling as a wrong value. A quick diff between two snapshots, taken minutes or months apart, usually surfaces the change faster than reading any changelog.
What you can do with it
Deploy regression checks
Snapshot headers before and after a release to catch a caching directive or content type that silently changed.
CDN and proxy debugging
Inspect which layer actually answered a request by reading server and cache-status headers instead of guessing from behavior.
Cookie and session auditing
Confirm session cookies carry the flags you expect across every environment, not just the one you happened to test in a browser.
FAQ
Can I check headers for a URL that requires redirects?
Yes, the task follows the response chain and returns the headers of the final response reached.
Is this free to use?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
How is this different from curl -I?
It does the same fetch but returns structured, parseable data asynchronously with a signed result, so it can run at scale inside pipelines instead of one URL at a time on a terminal.
Do I get charged for a failed request?
No. A failed task retries automatically up to three times and is never billed; only completed tasks are charged.
What should I compare in the headers before and after a release?
Look for headers that should stay stable, such as content type, caching policy and server identity, changing without warning, and for headers that have simply disappeared. A missing header often tells you as much as a wrong value.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/headers \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'const res = await fetch("https://api.kit.forhosting.com/web/headers", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/headers",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/headers", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/headers", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"url": "https://example.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.headers",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
timeout_sec | 30 |
max_crawl_pages | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This HTTP headers API fetches a URL and returns the complete raw header set as structured data, so you can inspect it in code instead of squinting at browser dev tools.
What comes back from the endpoint
Because the response is structured, you can filter for a single header programmatically instead of parsing raw text. Call POST /web/headers with a URL and the task fetches it and returns the full response header set exactly as the server sent it — content type, server identity, caching directives, cookies, custom application headers, everything present on the wire.
Why headers carry more signal than most people think
A caching header that quietly reverted, a server banner that leaked a stack you did not mean to expose, or a cookie flag that got dropped in a deploy are the kind of regressions that never show up by eyeballing a rendered page. HTTP headers have existed since the earliest version of the protocol as a way to pass metadata alongside content without touching the body, and that separation is exactly why they are so useful for automation: a header tells you what changed structurally even when the visible page looks identical.
How teams put it to work
Because the task is asynchronous and delivered by signed webhook, it slots naturally into a deployment pipeline as a post-deploy check, or into a monitoring job that snapshots headers on a schedule and diffs today's set against yesterday's. That turns a header inspection from a manual, occasional habit into a continuous, automatic guardrail.
Integration use cases
Third-party integration checks
Verify a partner API or embed still returns the content type and headers your integration was built to expect.
Technical questions
What does the HTTP headers API return?
The complete set of response headers for the requested URL, exactly as the server sent them, returned as structured data you can parse in code.
How do I receive the results?
Through a signed webhook when the task finishes, which we recommend for automation, or a signed link valid for 24 hours.
What is the price per request?
$0.002 per request, with no separate charge per header returned.
Can I check headers in bulk across many URLs?
Yes, submit each URL as its own async task and correlate results by task_id; the async model is built for exactly that kind of scale.