What this tool checks
Given a URL, this fetches it twice from Pingfloat's servers — once normally and once with compression explicitly declined — and reports the raw response headers, whether the response is compressed (gzip/brotli), whether it's cached by a CDN, and whether common security headers are present.
Why security headers matter
HTTP response headers like Content-Security-Policy and Strict-Transport-Security are instructions to the browser about how to treat the page defensively — they don't change what the page looks like, but they close off entire categories of attack (XSS, clickjacking, protocol downgrade) at the browser level, with no code changes needed on the page itself.
Common headers reference
| Header | What it does |
|---|---|
Authorization | Carries credentials (e.g. Bearer <token>) for authenticating a request. |
Retry-After | Sent with a 429 Too Many Requests or 503 Service Unavailable response — tells the client how long to wait before retrying, either as a number of seconds or an HTTP date. |
Idempotency-Key | A client-generated unique value (common in payment APIs like Stripe) that lets a server safely ignore an accidental duplicate request — e.g. a retry after a timeout — without double-processing it. Not yet a core IETF RFC, but widely supported as a de facto standard. |
Host | The domain (and port, if non-default) the client is requesting — the only header that's required on every HTTP/1.1 request, since it's what lets one server IP host multiple domains. |
Accept | Tells the server which content types the client can handle (e.g. application/json), so the server can choose the right response format. |
Frequently asked questions
Why does this tool make two requests instead of one?
Comparing a normal request against one with compression explicitly declined (Accept-Encoding: identity) reveals whether a server is properly negotiating compression, rather than just always compressing (or never compressing) regardless of what the client can handle.
Does this tool report the compression ratio or file size saved?
No — the browser's fetch layer transparently decompresses the response body before JavaScript ever sees it, and many real responses use chunked transfer encoding with no Content-Length header at all, so there's no reliable way to recover the true compressed size after the fact. This tool sticks to what's actually verifiable: which encoding was negotiated, from the headers themselves.
Is a missing security header always a problem?
Not necessarily — it depends on the site. An API that never renders untrusted HTML has less need for a Content-Security-Policy than a site accepting user-generated content, for example. Treat these as things worth a deliberate decision, not universal requirements.
Are HTTP header names case-sensitive?
No — per RFC 9110, HTTP header field names are explicitly case-insensitive: Content-Type, content-type, and CONTENT-TYPE are the same header. That's why this tool (and most HTTP libraries, including curl and the Fetch API) normalize header names to lowercase internally. Header values are a different story — some, like cookie names or Basic Auth credentials, are case-sensitive, so don't assume the same rule applies there.
Why am I getting a "431 Request Header Fields Too Large" error?
Most servers and reverse proxies cap the total size of request headers (commonly somewhere between 8KB and 16KB) to protect against abuse. This usually creeps up gradually — an accumulation of cookies, a large JWT stored in an Authorization header, or a long chain of forwarded headers from proxies — until a request finally crosses the limit and gets rejected with a 431. Run a page's own responses through this tool to see exactly which headers are present and roughly how large they are, as a starting point for tracking down which one grew too big.