devtools

HTTP Header Checker

Check the HTTP response headers of any URL: see the status, cache and cookie rules, plus security headers like HSTS, CSP, and nosniff. Server-side lookup.

How to use HTTP Header Checker

What it does & when you need it

Every HTTP response carries a set of headers — small key/value lines that travel alongside the body and tell the browser how to treat what it just received. This tool fetches those response headers for any public URL and lays them out so you can read them at a glance. Reach for it when you're debugging a cache that won't invalidate, checking whether a deploy actually shipped the security headers you configured, confirming a redirect lands where you expect, or auditing what a third-party endpoint quietly leaks about its stack.

Unlike most tools on Devtools, this one is not a browser-only utility. Your browser can't make an arbitrary cross-origin request and read the raw headers back, so the URL you enter is sent to our server, which performs the request on your behalf and returns what it saw. In other words, the URL leaves your device. Don't paste links that contain secrets in the query string (signed URLs, password-reset tokens, session ids); fetch the bare endpoint instead.

How to use

  1. Type or paste a full URL into the URL field, including the scheme — https://example.com. Press Sample on the example below to load one.
  2. Click Get headers (or press Ctrl/Cmd + Enter). The tool contacts the server, follows redirects, and reports back.
  3. Read the result card: the final URL (after any redirects), the HTTP status code, and the full list of response headers with each name in muted mono and its value beside it.

Things worth knowing

Headers describe behaviour, not just content. Cache-Control and ETag decide whether a browser or CDN reuses a cached copy or revalidates; Content-Type tells the browser how to parse the body (get it wrong and JSON renders as plain text, or a script won't execute); and Set-Cookie reveals how sessions are issued, including the Secure, HttpOnly, and SameSite flags that govern how safely they travel.

Security headers are the ones worth auditing. Strict-Transport-Security (HSTS) tells browsers to only ever reach the site over HTTPS, closing the downgrade window; Content-Security-Policy constrains which scripts, styles, and frames are allowed to load, your strongest defence against XSS; and X-Content-Type-Options: nosniff stops browsers from second-guessing a declared Content-Type and executing something as a script when it shouldn't. A missing one of these is a finding, not a nitpick. Pair this with an SSL certificate checker to see the transport story end to end.

It's deliberately light on the target. The tool issues a HEAD request first — that asks the server for its headers without sending the response body — and only falls back to a GET if the server rejects or mishandles HEAD. So you usually pull down metadata alone, not a full page.

Watch what the response gives away. The Server and X-Powered-By headers frequently disclose the exact software and version behind a site (nginx/1.25.3, Express, PHP/8.1). That's a free fingerprint for anyone scanning for known-vulnerable versions, which is why many teams strip or fake these headers in production. If you're checking your own site and see them, consider removing them.

Once you've read the headers, the URL metadata extractor pulls the page's title, description, and social-preview tags, and the URL encoder helps you build safe query strings before you test them here.

Examples

Inspect a homepage

https://example.com

Returns the HTTP status and every response header, including Content-Type and Cache-Control.

Audit security headers

https://github.com

Check a hardened site for HSTS, Content-Security-Policy, and X-Content-Type-Options: nosniff.

Trace a redirect

http://google.com

Watch the final URL differ from the input as the plain-HTTP request is upgraded and redirected.

Frequently asked questions

Does this send the URL to your server?

Yes. A browser can't read raw cross-origin response headers, so we fetch the URL server-side and return what we saw. Avoid URLs that carry secret tokens in the query string.

What request method does it use?

It issues a HEAD request first, which returns headers without the response body, and falls back to GET only if the server rejects HEAD. That keeps the request light on the target.

Why don't I see the request headers I sent?

This tool shows the response headers the server sent back, not the headers your browser sends. The status code and Content-Type also come from that response.

Which security headers should I look for?

Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options, and Referrer-Policy are the high-value ones to audit.

Does it follow redirects?

Yes. The result shows the final URL after any redirects, along with that response's status code and headers.

Why do Server and X-Powered-By matter?

They often disclose the exact software and version running a site, a free fingerprint for attackers scanning for known flaws. Many teams strip them in production.

Related tools

URL Metadata / OG PreviewPreview the Open Graph card Slack, Discord, and social sites build from a URL. Our server fetches the page and reads its og:title, og:image, and meta tags.SSL Certificate CheckerCheck a site's SSL/TLS certificate from our server: expiry date, days remaining, issuer, subject and the SAN list — even for expired or self-signed certs.DNS LookupLook up DNS records for any domain — A, AAAA, MX, TXT, NS, CNAME and SOA. Runs on our server so it works even behind a locked-down or private network.URL Encode / DecodeFree, private URL encoder and decoder that runs entirely in your browser. Percent-encode query values or whole URLs and decode %-escapes instantly.