HTTP headers lookup

HTTP headers lookup is a free tool that retrieves all HTTP response headers returned by a URL for a typical GET request.

What are HTTP response headers?

HTTP response headers are pieces of metadata that a web server sends before the response body, such as an HTML page, image or JSON document. They tell the client how to interpret, cache, redirect or secure the response.

An HTTP/1.x response normally begins with an HTTP status line, followed by the headers. In HTTP/2 and HTTP/3, the equivalent status is carried in the :status pseudo-header. The HTTP/1.x status line is technically separate from the headers, but it is commonly shown alongside them because it explains whether the request succeeded. A status such as 200 means the resource was returned, 301 or 302 indicates a redirect, 404 means the resource was not found, and 500 indicates a server-side error.

Headers may come from the origin server, a reverse proxy or a content delivery network such as Cloudflare. Some are added or removed as the response passes through those systems, so the result may describe more than the application that generated the page.

How do I use an HTTP headers lookup?

Enter the complete URL you want to check, including the scheme, such as https://www.example.com/account. The tool sends a typical GET request from its server and returns the HTTP headers received from that URL.

To compare response headers accurately, use the exact URL variants you want to investigate. The headers for http://example.com, https://example.com and https://www.example.com can differ because each address may have its own redirects, caching rules and server configuration.

URL syntax also affects the request:

• Spaces are not valid as raw URL characters and normally need percent-encoding, commonly as %20 in a path.
• ? introduces the query component, while & and = are commonly used by form-style query encodings but do not have those roles in every query string.
• Accented and non-Latin domain names are processed using IDNA and represented as ASCII A-labels, commonly beginning xn--, while path characters are generally encoded as UTF-8 bytes and then percent-encoded.
• A fragment beginning with # is handled by the browser and is not sent in the HTTP request.
• There is no universal maximum URL length. Very long URLs may be rejected by a server, proxy or application.

How do I read the HTTP header result?

Inspect the headers connected with the fault you are investigating. Header names are case-insensitive, although their values can have case-sensitive syntax.

Other headers can be application-specific. For example, Access-Control-Allow-Origin controls which origins may read a response through browser cross-origin requests. A Server header may name software or a proxy, but it is not reliable proof of the underlying platform because administrators can alter or remove it.

Practical troubleshooting scenarios

A redirect problem is one common reason to inspect headers. Suppose https://example.com/old-page returns status 301 with Location: https://example.com/new-page. That means the server is instructing the client to request the new address. Repeated checks of each destination can reveal a redirect loop or an unexpected change between HTTP and HTTPS.

For a stale page behind Cloudflare or another CDN, inspect Cache-Control, Age, ETag and any provider-specific cache header. A large Age value indicates the calculated age of the cached response, potentially including time in upstream caches, rather than how long a particular intermediary has retained it. It does not prove that every regional cache holds the same version.

When an API works in a server-side script but fails in a browser, examine Content-Type and the CORS response headers, including Access-Control-Allow-Origin. A JSON endpoint returning text/html may actually be serving an error page or login screen. Missing cross-origin permission can cause a browser to block access even though the server returned status 200.

Headers can also help with a site that appears unavailable. A 503 response points towards temporary server or upstream failure, while a 404 means the requested path was not found. They cannot diagnose every failure. If DNS resolution, TCP connection or TLS negotiation fails before an HTTP response exists, there may be no response headers to inspect. Ping can provide a separate connectivity check, while HTTP/2 Checker can check protocol support.

Why can a correct header result still look wrong?

A correct result can differ from your browser because caches, DNS records and request context may direct the two requests to different responses. This lookup runs on the server, so it may reach a different CDN node or resolve a recently changed DNS record sooner or later than your local network.

Browsers also send their own cookies, accepted content types, languages and cache validators. A logged-in WordPress page may therefore return different cache rules from an anonymous server request. Geographical routing and bot-management systems can also vary a response according to the source network or request headers.

After changing DNS, cached resolvers can continue using the previous record until its time to live expires. Once traffic reaches the new server, an old CDN object or browser cache may still return earlier content. Check the resolved host separately, purge caches where appropriate, and compare the exact URL rather than assuming every hostname uses the same configuration.

Frequently asked questions

Does this lookup show the request headers?

No. It retrieves the response headers returned by the URL for a typical GET request. Request headers are the metadata sent to the server and require separate browser developer tools, server logs or a command-line client to inspect fully.

Are URLs entered into the tool private?

The lookup is performed on the server. Your input travels to that server over HTTPS and is not stored. Avoid entering URLs containing passwords, access tokens or sensitive query parameters, because the destination server will also receive those values when requested.

Can HTTP headers explain a certificate warning?

Usually not on their own. The TLS connection is established before the HTTP response is sent, so an expired certificate, hostname mismatch or untrusted issuer may prevent any headers from being returned. Inspect the certificate and its chain separately when the browser warning happens before the page loads.

Why are several Set-Cookie headers returned?

A response may set more than one cookie, and each cookie uses its own Set-Cookie field. Do not combine them as though they were a comma-separated list, since cookie expiry dates can themselves contain commas. Review each cookie's domain, path and security attributes separately.

Can I compare the result with curl?

Yes. A command such as curl -D - https://example.com/ -o /dev/null prints response headers while discarding the body. Curl versions, request headers, redirect settings and network locations can produce a different result, so match those conditions before treating a difference as a server fault.