HTTP Headers & Compression Checker

An HTTP headers checker shows the lines a web server sends back before the page itself: the status, the content type, caching rules, cookies, security policies and how the body is compressed. Browsers read them on every request, but they never appear on screen, so problems hide in plain sight. Enter a URL and this tool fetches it the way a modern browser asks for it, lists every response header with a plain-English meaning, and checks the performance side: whether gzip or Brotli compression is on and how many bytes it saves, what the caching headers tell browsers and CDNs, whether Vary and Content-Type are right, whether HTTP/3 is advertised and which CDN appears to be in front of the site. You can copy all the raw headers in one click for a support ticket or a colleague.

How to use the HTTP headers

1. 1 Enter the full URLPaste the page, stylesheet, script or API address you want to inspect. Headers can differ from page to page, so check the exact URL you care about rather than just the home page.
2. 2 Run the checkWe request the URL with Accept-Encoding: br, gzip, follow up to five redirects through our safety checks, and record the final response. A second request without compression measures the real content size.
3. 3 Read the request detailsSee the final URL, status code, HTTP version, time to first byte, total time and the server or CDN that answered.
4. 4 Check compression and cachingThe compression card shows which encoding was used and the size sent compared with the uncompressed size. The caching result explains what Cache-Control, ETag, Last-Modified, Expires and Age mean for this response.
5. 5 Copy the headers or fix what is flaggedUse Copy all headers to paste the raw list into a ticket, then follow the server examples in the guide below for anything marked Improve.

What HTTP response headers are

Every time a browser asks for a URL, the server replies in two parts. First comes a status line and a block of headers, each a name and a value such as Content-Type: text/html; charset=utf-8. Then comes the body: the HTML, image or file itself. Headers are instructions and metadata. They tell the browser what kind of file it is receiving, whether it has been compressed, how long it may be kept, which cookies to store, and which security rules to apply.

Because headers are invisible in the page, they are easy to forget. A plugin update, a hosting move or a new CDN can quietly change them. A site can look perfect while sending pages uncompressed, telling every cache to store nothing, or advertising the exact software version it runs. A quick check of the full header list catches these problems before they cost speed or create risk.

This tool shows the complete list, in the order the server sent it, including repeated headers such as several Set-Cookie or Link lines. Common headers get a short explanation so you do not need to look each one up.

How compression works, and how to test gzip and Brotli

Text files such as HTML, CSS, JavaScript, JSON, XML and SVG compress very well, because they repeat the same words and tags many times. When a browser requests a page it sends an Accept-Encoding header listing the formats it can decode. Current browsers offer gzip and Brotli (br), and some also offer zstd. The server picks one, compresses the body, and says which it used in the Content-Encoding response header. If there is no Content-Encoding header, the body was sent as is.

To check if gzip is enabled, or whether a server prefers Brotli, this tool sends Accept-Encoding: br, gzip and reports the Content-Encoding that comes back. It then makes a second request asking for no compression (Accept-Encoding: identity) and compares the two sizes, so the saving you see is measured rather than estimated. If the server does not compress at all, we compress the body ourselves with gzip at a typical level to show roughly what you could save.

Brotli was designed for the web and usually produces smaller text files than gzip at comparable speeds, which is why most CDNs serve it by default. Gzip is still perfectly acceptable and every browser supports it. The real problem is sending text with no compression at all. Images, video, WOFF2 fonts and zip files are already compressed, so applying gzip or Brotli to them adds work for almost no gain; the checker does not flag those.

• br: Brotli. The best common choice for text over HTTPS.
• gzip: universally supported and a good fallback.
• zstd: newer and fast, supported by recent Chrome and Firefox releases.
• No Content-Encoding: the response was sent uncompressed.

How to enable gzip and Brotli on Apache, Nginx, LiteSpeed and Cloudflare

On Apache, gzip comes from mod_deflate and Brotli from mod_brotli, which ships with Apache 2.4.26 and later. Both are switched on per content type, usually in the virtual host or an .htaccess file. Many shared hosts have mod_deflate enabled already and only need the AddOutputFilterByType rule shown in the examples below. Ask your host if mod_brotli is available before adding Brotli rules; the IfModule wrapper keeps the file safe if it is not.

On Nginx, gzip is built in. Set gzip on, add gzip_vary on so caches keep separate copies, and list the text types in gzip_types (text/html is always included). Brotli needs the ngx_brotli module, which some distributions and builds include and others do not. Once it is loaded, the brotli and brotli_types directives mirror the gzip ones. Reload Nginx after any change and test again.

LiteSpeed Web Server, common on cPanel hosting, compresses static and dynamic text responses through its own compression settings, and recent versions can serve Brotli. On shared hosting you usually cannot reach the server settings, but LiteSpeed reads Apache-style mod_deflate rules in .htaccess, and caching plugins such as LiteSpeed Cache for WordPress expose related options.

Cloudflare compresses eligible text responses to visitors automatically, using Brotli or gzip depending on what the browser supports, even when your origin server sends them uncompressed. Its Compression Rules let you fine-tune which content is compressed and how. If the checker shows a Cloudflare response with no Content-Encoding, check whether the content type is one Cloudflare compresses and whether a rule or a Cache-Control: no-transform header is preventing it.

Caching headers explained

Cache-Control is the main caching header. max-age sets how many seconds a browser may reuse its copy, and s-maxage does the same for shared caches such as CDNs. no-cache does not mean "do not cache": it means a copy may be stored but must be checked with the server before each use. no-store means nothing may be kept at all. private limits storage to the visitor's own browser, and public allows shared caches to store responses they otherwise might not. immutable tells browsers the file will never change at that URL, so they skip revalidation entirely.

ETag and Last-Modified are validators. When a cached copy needs checking, the browser sends them back and the server can reply 304 Not Modified with no body, which is much faster than downloading the file again. Expires is the older way of setting a lifetime and is ignored when Cache-Control max-age is present. Age shows how many seconds a copy has spent in a shared cache, which is a good sign that a CDN served it.

For HTML pages there is no single right answer, so the checker describes the policy rather than grading it. Logged-in pages, carts and checkouts should be private or no-store. Pages that change often work well with no-cache plus an ETag. Mostly static marketing pages can carry a short max-age if you can purge the CDN when you publish. Static assets are different: CSS, JavaScript, images and fonts should get a long max-age, ideally with a version or hash in the file name, and the checker flags them when they do not.

Other headers worth checking

Vary lists the request headers that change the response. When a response is compressed and can be stored by shared caches, it should include Vary: Accept-Encoding so a cache never hands a Brotli copy to a client that cannot read it. Content-Type should name the file type and, for text, the character set; text/html; charset=utf-8 avoids garbled accents and symbols. Alt-Svc advertises HTTP/3, which runs over QUIC and helps most on slow or unreliable mobile connections.

Server, Via and X-Powered-By reveal the software and proxies behind a site. Server is harmless in short form, but X-Powered-By with a version number gives attackers a head start and can usually be removed. Headers such as cf-ray, x-amz-cf-id, x-served-by, x-cache and cf-cache-status reveal a CDN and whether the response was a cache hit. The checker uses these to suggest which CDN is in front of the site, but it is a best guess, as some providers hide their headers.

Strict-Transport-Security, Content-Security-Policy, X-Frame-Options and the other security headers appear in the table with short meanings. To grade them in detail, with copy-paste fixes for each one, use our Security Headers Checker. To trace each redirect hop and its status code, use the Redirect Checker or the HTTP Status Code Checker.

What this checker can and cannot tell you

The results reflect one request from our server, which is located in Europe, at one moment. Sites behind a CDN may answer differently in other regions, to logged-in visitors, or to traffic their firewall treats as automated. Some servers block checkers outright, in which case you will see an error or a challenge page instead of the real headers. Timings include connection setup and any redirects, so treat them as a rough guide and test more than once before drawing conclusions.

The headers list is read from an HTTP/1.1 request, which is how our checker fetches pages safely with a size limit. A separate lightweight request offering HTTP/2 shows which version the server negotiates. Bodies larger than 3 MB are read only up to that limit, and the sizes are marked accordingly. Your browser's developer tools (the Network tab) remain the best way to see exactly what your own browser receives from your location.

Examples you can copy

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css text/xml application/javascript application/json application/xml image/svg+xml
</IfModule>
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/javascript application/json application/xml image/svg+xml
</IfModule>

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml application/javascript application/json application/xml image/svg+xml;

# Only with the ngx_brotli module loaded:
brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css text/xml application/javascript application/json application/xml image/svg+xml;

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|svg|png|jpg|jpeg|webp|avif|woff2)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

location / {
    add_header Cache-Control "no-cache";
}

location ~* \.(css|js|svg|png|jpg|jpeg|webp|avif|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# Which encoding does the server choose?
curl -sI -H "Accept-Encoding: br, gzip" https://example.com/ | grep -i content-encoding

# Bytes sent compressed vs uncompressed
curl -s -H "Accept-Encoding: gzip" -o /dev/null -w "%{size_download}\n" https://example.com/
curl -s -H "Accept-Encoding: identity" -o /dev/null -w "%{size_download}\n" https://example.com/

Common mistakes to avoid

Frequently asked questions