HTTP Header Viewer
Fetch a URL and inspect its response headers
100% free. This tool needs our server to do the work, so what you submit is sent there, processed and then discarded - it is never stored.
Enter a URL above and click Inspect to view its response headers.
About this tool
Fetch a URL and displays exactly what HTTP response headers it returns - useful for debugging caching behavior, checking security headers, verifying redirects, or understanding how a server is configured to respond, without needing browser developer tools open.
How to use this tool
- Enter the target URLPaste the full public URL you want to inspect, including protocol (https://).
- Fetch response headersRun the request and capture the server-returned header set.
- Review key header groupsCheck caching, security, content, and redirect-related headers in one view.
- Compare after config changesRe-run after server updates to confirm headers are deployed correctly.
Which HTTP headers to check
For caching, look at Cache-Control, ETag and Age, and CDN headers such as cf-cache-status or x-vercel-cache. For security, check Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy. For SEO, check the status code, any Location redirect and X-Robots-Tag.
A 301 or 308 redirect is permanent and passes ranking signals; 302 and 307 are temporary. An X-Robots-Tag of noindex keeps the page out of search results even if the HTML looks fine.
Key features
- Quickly validates real response headers without opening browser devtools.
- Useful for SEO, performance, and security checks from one endpoint call.
- Helps detect CDN/cache misconfiguration early.
- Supports faster verification during deployment troubleshooting.
Common uses
- Checking Cache-Control and ETag behavior after release.
- Verifying security headers like CSP, HSTS, and X-Frame-Options.
- Debugging redirect chains and canonical URL responses.
- Auditing API response headers for cross-team integration readiness.
Tips for better results
- Always test both `www` and non-`www` variants if your site uses redirects.
- Compare headers across staging and production to catch drift.
- Validate that cache headers match asset type and update frequency.
- Use HTTPS endpoints for meaningful security-header audits.
Mistakes to avoid
- Assuming browser-cached results reflect current server configuration.
- Checking only status code and ignoring missing security headers.
- Auditing one route while other templates return different headers.
- Confusing proxy/CDN headers with your application-level headers.
Frequently asked questions
Common ones include Content-Type, Cache-Control, Set-Cookie, security headers like Content-Security-Policy, and server information - exactly what the target server chooses to send back.
Publicly accessible URLs generally work; some servers may block requests that don't look like they're coming from a real browser, which could affect what headers you see.
Common reasons: debugging why caching isn't working as expected, verifying security headers are configured correctly, or understanding a redirect chain when a URL doesn't go where you expect.
Look at Cache-Control for the caching rules, and at Age, X-Cache or CF-Cache-Status for whether the response came from the CDN. A HIT means it was served from cache; MISS means it went to the origin server.
A 301, 302, 307 or 308 response carries a Location header with the destination. 301 and 308 are permanent - search engines move rankings to the new URL - while 302 and 307 are temporary.
The status code, any X-Robots-Tag (which can noindex a page invisibly), Link headers with canonical URLs, and Content-Type. A stray X-Robots-Tag: noindex is a common reason a page will not get indexed.