{{ curlCommand }}
Header | Value |
---|---|
{{ k }} | {{ v }} |
{{ raw_header }}
Hyper-text transfer protocol (HTTP) response headers convey status codes, caching rules and server metadata that browsers interpret before rendering a resource. Understanding these fields is vital for diagnosing redirect loops, security warnings and sluggish loads.
This tool sends a configurable request to any publicly reachable URL, then displays the status line, each returned header, redirect chain and total round-trip time. A ready-to-run curl
command mirrors your settings for repeatable shell tests.
Use it to verify new cache rules after a deployment or to confirm that a mobile crawler sees the same headers as a desktop client. A remote origin may block or rate-limit frequent probes.
HTTP is a request–response protocol layered over TCP or TLS. Each server reply starts with a status line—protocol, numeric status and reason phrase—followed by colon-separated header fields that influence caching, compression, authentication and content negotiation. Analysing this metadata enables performance tuning and security hardening.
Location
responses when redirects are allowed, repeating steps 2–4.Class | Description |
---|---|
1xx | Informational — provisional reply |
2xx | Success — request fulfilled |
3xx | Redirection — further action required |
4xx | Client error — request faulty |
5xx | Server error — server failed to complete request |
Only the last code in a redirect chain represents the resource ultimately shown to the user; intermediate codes guide user-agents silently.
Parameter | Meaning | Typical Range |
---|---|---|
URL | Target resource to probe | Any valid absolute URL |
HTTP method | HEAD returns headers only; GET returns body plus headers | HEAD | GET |
Accept-Encoding | Advertises compression algorithms you accept | gzip, br, deflate, identity |
User-Agent | Spoofs client identity for device-specific testing | Desktop, Mobile, Bot or custom string |
Follow redirects | Toggle automatic rewrites on 3xx codes | true | false |
Timeout | Maximum wait before abort (seconds) | 1–60 s |
Extra headers | Arbitrary key–value pairs appended to request | Any RFC 7230 field |
Request: HEAD https://example.com
, timeout 15 s.
HTTP/1.1 200 OK Cache-Control: max-age=604800 Content-Type: text/html; charset=UTF-8 Content-Length: 1256 Server: ECS (chi/55B2)
Total time ≈ 0.210 s, no redirects encountered.
Behaviour aligns with RFC 9110 (HTTP/1.1 semantics), RFC 9113 (HTTP/2) and the IANA HTTP Status Code Registry.
No personal data is required; requests are sent client-side and are subject to the same regulatory scope as ordinary browsing traffic.
Follow these steps to replicate any HTTP response under controlled conditions:
No. Your request parameters remain in your browser and the fetched JSON is neither logged nor persisted.
The checker offers HEAD for lightweight header probes and GET when you also need payload-dependent headers such as Content-Length
.
No. The underlying fetch stack enforces the browser’s certificate policy and rejects untrusted chains.
The tool measures client-side wall clock time from request dispatch to final bytes received, not including DNS cache hits.
Yes. The displayed total aggregates all hops, giving a realistic end-to-end latency figure.