What an HTTP header check reveals
Every HTTP response begins with a status and a set of headers before its body. Those headers describe how clients should handle the response: where to redirect, what media type follows, how long a cache may reuse it, whether cookies are being set, and which browser security policies apply. They can expose a configuration problem without downloading or reading the entire page.
This checker makes a request from the PagesTools server to a public HTTP or HTTPS URL and presents the returned status and headers. Results represent that server-side request at that moment. A destination may vary its response by location, IP reputation, protocol, user agent, accepted encodings, authentication, cookies, or CDN edge, so your browser can legitimately receive different headers.
How to inspect a URL
- Enter one complete public URL with an HTTP or HTTPS scheme.
- Run the request and record the first status code.
- Inspect any Location header and each redirect hop shown.
- Review caching, content-type, cookie, and security headers relevant to your goal.
- Compare the result with your browser or command line if behavior differs by client.
Use a canonical URL without private credentials or sensitive query parameters. If you are testing a recently changed CDN rule, repeat after the expected propagation interval and inspect more than one region using infrastructure you control. A single remote check cannot prove that every edge or visitor receives the same response.
Understand common status codes
A 200-class response indicates the request succeeded in protocol terms. A 301 or 308 describes a permanent redirect, while 302, 303, and 307 have different temporary and method-handling semantics. A 304 tells a conditional client to reuse its cached representation. A 404 means that route was not found, a 429 indicates rate limiting, and a 500-class status points to trouble at the server or a gateway.
Status alone does not prove that the correct content was returned. A custom error page can mistakenly return 200, and a CDN can serve a cached success while the origin is unhealthy. Pair the header result with content inspection and application monitoring when diagnosing an incident.
Headers worth checking
Content and caching
Content-Type should match the representation and include a charset where text interpretation needs one. Cache-Control defines reuse rules; Age can show how long a shared-cache response has existed; ETag and Last-Modified support revalidation. CDN headers are vendor-specific and should be read with that provider's documentation.
Redirects and canonical hosts
The Location value identifies the next address. Follow every hop to catch loops, HTTP-to-HTTPS-to-hostname chains, lost paths, or encoded query errors. A permanent migration should normally reach the final canonical page in one hop when the hosting architecture allows it.
Browser security policy
Headers such as Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy can reduce browser attack surface. Their presence alone is not enough: an overly broad CSP may provide little protection, and HSTS should be enabled only after HTTPS works across the intended host scope. Test policy behavior in browsers and use report-only deployment where appropriate.
Concrete diagnostic use cases
Check a newly deployed page to confirm its content type and cache lifetime, trace an old campaign URL to its current destination, or compare headers before and after enabling a CDN rule. During an incident, the report can show whether a gateway is returning 502, a rate limiter is returning 429, or a stale shared cache is still serving an earlier response.
Cookies and authentication limits
A Set-Cookie header can reveal cookie names and flags, but the checker should not establish your private browser session or forward its cookies. Protected pages will commonly return a login response. Never put a password or bearer token in a URL. To troubleshoot authenticated traffic, use local developer tools on an authorized device and redact secrets before sharing captures.
Privacy and server-side requests
The URL you enter is sent to PagesTools because the request runs on its server. The destination can observe the PagesTools server's IP address, request time, request method, and user-agent details; it does not receive your browser's IP as the direct requester. Query strings are part of the submitted URL and may be visible in service or destination logs, so remove tokens and personal data.
Only public destinations should be accepted. Private, loopback, link-local, metadata-service, and other restricted address ranges must be blocked, including after DNS resolution and redirects, to prevent server-side request forgery. Use the checker on URLs you own or are permitted to diagnose, and do not use repeated requests as a load test.