HTTP Headers Inspector

A demonstration table for learning response headers

The HTTP headers inspector on this page currently provides a fixed example rather than querying the URL you enter. With any nonempty endpoint value, it displays five illustrative response headers: Content-Type, Server, X-RateLimit-Limit, X-Frame-Options, and Content-Encoding. Editing the field causes React to refresh that same sample list. Clearing the field hides the rows.

That behavior is important to understand before using the output in a support ticket or security review. There is no fetch, XMLHttpRequest, proxy API, HEAD request, or server action in the component. The default https://api.github.com text and GitHub-flavored values are demonstration data; they are not a live snapshot and may not match GitHub’s current response. The tool does not validate the entered URL or make any network request to it.

Use this page to become familiar with header names and to discuss what a response-header report looks like. For live diagnostics, use browser DevTools, curl, or another authorized HTTP client and interpret the real response in context.

How an actual HTTP response is structured

In HTTP/1.1, a response conceptually begins with a status line, followed by header fields and then an optional message body:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Cache-Control: max-age=60

{"status":"ok"}

HTTP/2 and HTTP/3 encode fields differently on the wire and use a :status pseudo-header rather than a textual status line, but developer tools usually present a familiar name/value view. Field names are case-insensitive. Their values can describe representation format, caching, content negotiation, authentication, redirects, transport policy, tracing, rate limits, and intermediary behavior.

Request headers and response headers have different directions. Accept tells a server what representations a client can consume; Content-Type describes the representation actually sent. Authorization carries client credentials; WWW-Authenticate describes an authentication challenge. A useful HTTP header checker must preserve that distinction.

Reading the five sample rows

Content-Type: application/json; charset=utf-8

Content-Type is a media type plus optional parameters. application/json tells a client to parse JSON rather than HTML, text, or an image. The charset parameter identifies character encoding, although current JSON interoperability requirements already center on UTF-8. A filename extension does not override this HTTP metadata.

If an API accidentally sends JSON as text/html, clients, gateways, browsers, and security controls may handle it incorrectly. Conversely, a declared JSON type does not guarantee valid JSON; parsing the body is still necessary.

Server: GitHub.com

The Server field can identify software handling the response. Administrators often minimize detailed version disclosure, but removing a banner does not patch vulnerabilities or hide infrastructure from determined analysis. Proxies and CDNs may insert, rewrite, or remove it. The sample value is static and should not be taken as evidence about the entered endpoint.

X-RateLimit-Limit: 60

Rate-limit fields communicate policy, but X-RateLimit-Limit is not a universally standardized contract. Providers may also return remaining quota, reset time, bucket identifiers, or standardized RateLimit fields. Read the API’s documentation and consider authentication scope, resource category, and rolling versus fixed windows. A limit without a remaining count or reset policy is incomplete operational information.

X-Frame-Options: deny

This response header tells supporting browsers not to render the page in a frame. DENY blocks framing by all origins; SAMEORIGIN permits same-origin framing. Modern applications can express more flexible framing policy through Content Security Policy’s frame-ancestors directive. The header helps mitigate clickjacking but does not provide general cross-site scripting protection.

Content-Encoding: gzip

Content encoding describes a transformation applied to the representation for transfer, commonly gzip, br, or zstd. Browsers transparently decompress supported encodings. It differs from Content-Type, which identifies the underlying media format. Servers should coordinate encoding with content negotiation and caching, often through Accept-Encoding and Vary.

Retrieve real headers with browser DevTools

Open the target page or reproduce the API request, then open the browser’s Network panel. Reload, select the relevant request, and inspect Response Headers. This view shows what the browser exposed for that transaction and often separates provisional, request, and response fields.

Choose the correct request. A document can load scripts, fonts, API calls, redirects, and images, each with its own headers. If diagnosing caching, enable and disable DevTools cache intentionally and note whether the result came from memory, disk, a service worker, or the network. Preserve logs when following redirects so intermediate 301, 302, 307, or 308 responses are not lost.

Browser displays can normalize names and show decoded body sizes. HTTP/2 and HTTP/3 details may appear separately. For CORS failures, the Network panel can contain a response that page JavaScript is not permitted to read; DevTools visibility and Fetch API visibility are not equivalent.

Retrieve real headers from a terminal

For an endpoint you are authorized to query, a HEAD request is concise:

curl -I https://example.com/resource

However, HEAD is not always implemented correctly, and servers can return different metadata than for GET. To issue GET while discarding the body, use:

curl -sS -D - -o /dev/null https://example.com/resource

Add -L only when you intend to follow redirects. Without it, you can inspect the first redirect’s Location; with it, include appropriate output options to distinguish each response block. Avoid placing bearer tokens or cookies directly in shared shell history. Redact Set-Cookie, Authorization, internal hostnames, request IDs, and account-specific limits before posting output.

A diagnostic exercise: stale API data

Suppose an API returns old data after a deployment. A real inspection might find:

Cache-Control: public, max-age=300
Age: 290
ETag: "release-41"
Vary: Accept-Encoding
Via: 1.1 edge-cache

Age suggests a shared cache served the response. max-age=300 permits freshness for five minutes, and the ETag identifies a validator. The next questions are whether invalidation reached the edge, whether the cache key varies on required request properties, and whether authenticated data was incorrectly marked public. This sample page cannot perform that investigation because it neither contacts the endpoint nor displays those fields.

For a file download problem, compare Content-Type, Content-Disposition, Content-Length, Content-Encoding, and range-related fields. For an authentication issue, examine the status, WWW-Authenticate, cookie attributes, redirect chain, and CORS response. No single header has meaning in isolation.

Why a browser-only live inspector is difficult

The same-origin policy prevents arbitrary page scripts from reading cross-origin responses. A target can grant access with Access-Control-Allow-Origin, but even then JavaScript sees only CORS-safelisted response headers unless Access-Control-Expose-Headers permits more. A failed CORS check is not proof that the server is offline.

Using mode: no-cors would not solve inspection: it produces an opaque response whose status, headers, and body cannot be read by JavaScript. A live general-purpose inspector usually requires a server-side fetch proxy, which introduces server-side request forgery risks, access controls, logging, private-network protections, redirect limits, and privacy obligations. The present component avoids all of that by showing static data, but its output must be labeled mentally as educational.

Privacy and safety boundaries

Typing an endpoint into this component does not send the endpoint to that host or to a lookup API. It remains in browser state and is used only to decide whether to show the fixed rows. Normal site hosting and analytics behavior, if any, is outside this component’s header logic, but there is no component-level request tied to the input.

Do not paste secrets into a URL field. URLs can contain tokens and personal identifiers, and browsers, extensions, screenshots, clipboard managers, or surrounding telemetry may expose them even when a particular component does not fetch. Prefer sanitized endpoints.

Inspect systems you own or are permitted to test. Ordinary GET and HEAD requests can trigger work, create logs, consume quotas, or alter state on badly designed endpoints. Never assume HEAD is harmless, and avoid probing internal or third-party URLs outside an approved scope.

Troubleshooting the demonstration

If rows do not change when you replace the URL, that is expected: all nonempty values produce the same five objects. If rows disappear, check whether the field is empty. There is no loading state, error state, status code, refresh action, copy behavior, redirect handling, URL parsing, or live comparison in this implementation, despite several unused icon imports.

If you need exact current headers, do not retry different URLs here. Capture the request with DevTools or an HTTP client. When results differ between clients, align the method, URL, DNS path, HTTP version, request headers, cookies, authentication, redirect behavior, cache state, and network location.

Header-inspection questions

Are the displayed GitHub headers current?

No. They are constants in the React component and are not retrieved from GitHub.

Does changing the endpoint issue a HEAD request?

No. The component reacts locally to the string and never calls fetch.

Can response headers contain sensitive data?

Yes. Set-Cookie, internal tracing, infrastructure names, signed URLs, quota details, and custom metadata may be sensitive. Redact before sharing.

Why does curl -I differ from a browser GET?

Method, request headers, cookies, content negotiation, cache, redirects, CDN policy, geography, and protocol can all change a response. Reproduce the original request as closely as practical.

Is X-Frame-Options enough for framing policy?

It remains useful for older clients, but CSP frame-ancestors provides modern, flexible control. Test the delivered policy on every relevant HTML response.

Can JavaScript read every header when CORS is enabled?

No. Cross-origin scripts receive safelisted headers plus fields explicitly exposed by the server. DevTools may show more than application code can access.