HTTP Header Checker
Look at the headers a server sends before the page itself. Enter a URL to get the complete list, sorted into security, caching, cookie, content and server headers, with a plain-language explanation next to each one.
- Encrypted connection
- No sign-up
- Free to use
How to use HTTP Header Checker
- Enter the web address you want to inspect.
- Choose the request method and which kind of client to request as, and whether redirects should be followed.
- Select Get headers.
- Read the grouped headers and their explanations, and check which recommended security headers are present.
HTTP Header Checker features
Every header, including duplicates
Repeated headers such as Set-Cookie are all listed, in the order the server sent them.
Grouped and explained
More than forty common headers come with a short description of what they do.
Security header overview
Shows which of the six recommended security headers a site sends.
Client variations
Request as a desktop browser, a phone, Googlebot or a plain client to see whether the server answers differently.
GET or HEAD
Compare the two methods; some servers misconfigure HEAD responses.
Timing and protocol
HTTP version, DNS, connect, TLS and time to first byte for the request.
When to use HTTP Header Checker
- Checking that caching headers are set the way you intended after a deployment.
- Verifying security headers such as HSTS and Content-Security-Policy.
- Debugging why a file downloads instead of displaying, or the other way round.
- Seeing whether a site serves different headers to search engine crawlers or mobile devices.
HTTP Header Checker FAQ
What are HTTP headers?
Lines of metadata that accompany every request and response on the web. Response headers tell the browser what it is receiving, how long it may cache it, which security rules apply, which cookies to store and where to go next in the case of a redirect. They are processed before the page is displayed and are normally invisible.
What is the difference between GET and HEAD?
GET asks for the resource including its body. HEAD asks for the headers only, which is faster. The headers should be identical, but some applications treat HEAD differently or do not support it, so comparing both can reveal problems that crawlers and monitoring tools may run into.
Which security headers should a site send?
For an HTTPS site: Strict-Transport-Security, X-Content-Type-Options with nosniff, a frame restriction through X-Frame-Options or the frame-ancestors directive, a Referrer-Policy, and ideally a Content-Security-Policy and a Permissions-Policy. The checker lists each with its status.
Why do the headers differ from what my browser shows?
Servers respond according to the request. Cookies, language, location, the user agent and whether you are logged in can all change the result. This tool sends a request without cookies from our server, so it shows what a first-time visitor or a crawler would receive.
Does “request as Googlebot” show exactly what Google sees?
It sends Googlebot's user agent string, which is enough to reveal content or redirects that depend on the user agent. Sites that verify crawlers by their IP address will still recognise that the request does not come from Google.
Is it safe to expose the Server and X-Powered-By headers?
They are not a vulnerability in themselves, but exact version numbers help an attacker pick a matching exploit. Most guidelines recommend removing X-Powered-By and reducing Server to the product name.
Why response headers matter
A great deal of a website's behaviour is decided in a few lines that visitors never see. Whether a returning visitor gets the page instantly from cache or waits for a full download depends on Cache-Control. Whether a session cookie can be stolen by a script depends on its HttpOnly flag. Whether a browser will ever try an unencrypted connection again depends on Strict-Transport-Security. Looking at the headers is the fastest way to check all of this without access to the server.
Caching headers are the ones most often set wrongly. Static files with a version in their name can safely be cached for a year, while HTML pages usually need revalidation so that updates appear. When a site sits behind a CDN, additional headers such as Age and the provider's cache status show whether a response really came from the edge or had to be fetched from the origin server, which explains many “the site is slow for some visitors” reports.
Security headers form the second big group. Each one closes a specific gap: forcing HTTPS, forbidding framing by other sites, stopping content-type guessing, limiting where scripts may come from. They cost nothing to send, and their absence is the first thing an automated security scan will report.
Finally, headers are the source of truth when something behaves oddly. A redirect loop, a download prompt for a page, a missing compression, text shown in the wrong character set: each has a header that explains it. Comparing the headers of a working and a broken URL usually points straight to the cause.