How to Show HTTP Response Headers with cURL?

How to View HTTP Headers Using Different Techniques

A quick HEAD request with curl -I

The fastest way to see HTTP response headers only is a HEAD request.

curl -I https://anonymous-proxies.net

What happens here:

• -I switches the method to HTTP HEAD
• The server returns headers only, without the body
• You get a short, scannable block of information

If the site redirects (HTTP 301 / 302) and you want to see every hop, just add -L.

curl -I -L https://anonymous-proxies.net

Now curl prints headers for each redirect plus the final page.

Seeing headers and body together with -i

When you are testing an API or JSON endpoint, it is nice to see headers and body in one go.

curl -i https://api.example.com/users/123

Basically what happens is this.

• -i (or --include) prints the response headers first
• Then a blank line
• Then the body (HTML, JSON, etc.)

This is perfect when you want to confirm the status code, Content-Type and the actual JSON payload without running separate commands.

Dumping only headers from a GET with -D and -o

Some servers behave differently for HEAD vs GET, so it is often safer to inspect headers from a real GET request.

To print only the headers from a GET, try the script below.

curl -s -D - -o /dev/null https://anonymous-proxies.net

What each flag does:

• -s hides the progress meter
• -D - dumps the response headers to standard output
• -o /dev/null discards the body

If you want to save the headers to a file for later, write this in your terminal.

curl -s -D response-headers.txt -o /dev/null https://example.com

Now response-headers.txt is ready to be searched, shared with your team or committed to a repo.

Full request and response debugging with curl -v

When things get weird, verbose mode can give you the full picture.

curl -v https://example.com -o /dev/null

Verbose output shows:

• The request line and headers you send (prefixed with >)
• The response status line and headers you receive (prefixed with <)
• Protocol version, connection reuse, TLS details, and more

Issues You Often See When Working with HTTP Headers

HEAD and GET don’t tell the same story

A common mistake is to assume curl -I tells you the full truth. In reality, some servers:

• Set cookies only on GET
• Use different caching headers for HEAD
• Implement HEAD in a minimal or buggy way

If something does not add up, compare these 2 scripts.

curl -I https://example.com
curl -s -D - -o /dev/null https://example.com

Use the GET version as the reference for real user behavior.

Redirects hiding the real headers

If you only run:

curl -I https://example.com

you might only see the first 301/302. The final page (where users actually land) may have completely different headers.

Always add -L when you care about the final response:

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

This exposes all the redirect steps and the final Cache-Control, Set-Cookie, and security headers.

Proxies quietly rewriting or triggering headers

When you send requests through our residential proxies, some sites adapt behavior based on IP, country or ASN. You may see:

• Different Set-Cookie values
• Geo-specific Content-Language
• Extra security or rate limit headers

An example is:

curl -s -D - -o /dev/null \
  -x http://user:pass@res-proxy-host:8000 \
  https://target-site.com

Compare this with the same command run without -x. Any differences in headers tell you how that site treats traffic from different IP ranges.

Too many headers, not enough signal

Modern responses can have a lot of headers. When you only care about one or two, scrolling through everything is a waste of time.

Filter headers in the shell:

Only cookies:

curl -s -D - -o /dev/null https://example.com \
  | grep -i '^set-cookie'

Caching related headers:

curl -s -D - -o /dev/null https://static.example.com/app.js \
  | grep -Ei 'cache-control|expires|etag|age'

This keeps your focus on the values that actually matter for the problem you are solving.

How cURL Is Commonly Used to View HTTP Headers

Checking website behavior from different IPs

One of the most powerful combinations is curl plus our residential proxies. You can see how a site behaves from multiple countries and networks without leaving your terminal.

For example, you can test a URL through one of our endpoints:

curl -s -D - -o /dev/null \
  -x http://user:pass@res-proxy-host:8000 \
  https://target-site.com

With this pattern you can compare:

• Status codes (200 vs 403/429)
• Geo-based redirects (Location)
• Region-specific cookies and personalization

Debugging caching and CDN headers on live sites

Headers are the main way to understand CDN and browser caching rules. A very common way to inspect caching for a static asset is to run the script below.

curl -s -D - -o /dev/null https://static.example.com/app.js \
  | grep -Ei 'cache-control|expires|etag|age'

With one short command, you can instantly see how long the asset is allowed to stay in cache through directives.

Inspecting login flows, sessions and API behavior

When you move to login flows and APIs, headers become even more important. For a login page, you can run the script below.

curl -s -D - https://example.com/login -o /dev/null

Here you look at Set-Cookie, security flags like Secure and HttpOnly, SameSite, and any redirect locations.

For an API endpoint, something like this works well.

curl -i https://api.example.com/data

When you look closely at the response headers, you can instantly confirm that the server is really sending JSON by checking the Content-Type. You can also see any rate limiting headers that tell you how often you are allowed to hit the API before it starts rejecting requests.

Conclusion

Once you get comfortable reading HTTP headers with curl in quiet mode, you unlock a serious advantage in web development. You can spot why an API is failing without guessing, understand why a scraper suddenly broke, and catch misconfigurations that might slow things down or block requests entirely. You now have several practical ways to inspect exactly what a server sends back and to pick the right approach for each situation. If you ever want a second pair of eyes on an issue, our support team is always here to help.