Response headers in HTTP responses carry key metadata such as status codes, content types, cache directives, and cookies, which determine how clients interpret and handle the body. Observing these fields reveals how servers signal success, errors, redirects, and expiration rules. Careful header inspection helps isolate issues that do not appear in the response body alone.

The HTTP protocol sends a status line and headers before any body data, while cURL prints only the body by default. Options such as --include, --head, and --verbose adjust this behavior so headers appear together with or instead of the body. Additional switches like --dump-header can store headers separately for comparison between servers or configuration changes.

Differences between HEAD and GET handling, intermediate proxies, and TLS termination layers can all influence observed headers. Some deployments add or strip fields such as X-Forwarded-For or Set-Cookie, and verbose logging may expose sensitive values if captured without care. Using cURL options deliberately keeps header analysis reliable while minimizing accidental leakage of tokens or session information.

Related: How to view HTTP request headers in cURL
Related: How to set custom headers in cURL requests

Steps to show HTTP response headers in cURL:

  1. Open a terminal where cURL is available. 
    $ whoami
root
  2. Send a GET request with --include to print response headers above the body. 
    $ curl --silent --include "http://api.example.net/"
HTTP/1.1 200 OK
Server: sg-httpbin-lite/1.0 Python/3.12.3
Date: Sat, 10 Jan 2026 05:11:09 GMT
Content-Length: 62

<!doctype html><html><title>Mock API</title><h1>OK</h1></html>
##### snipped #####

    Flag --include adds the status line and response headers before the body so header fields and content can be reviewed together.

  3. Send a HEAD request with --head to show only response headers without the response body. 
    $ curl --silent --head "http://api.example.net/"
HTTP/1.1 200 OK
Server: sg-httpbin-lite/1.0 Python/3.12.3
Date: Sat, 10 Jan 2026 05:11:09 GMT
Content-Length: 62
Content-Type: text/html

    Some servers generate HEAD responses differently from GET, so headers from --head may not exactly match those seen during a full GET and can misrepresent behavior under real traffic.

  4. Enable verbose mode with --verbose to inspect both request and response headers and connection details. 
    $ curl --silent --verbose "http://api.example.net/"
* Host api.example.net:80 was resolved.
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:80...
* Connected to api.example.net (127.0.0.1) port 80
> GET / HTTP/1.1
> Host: api.example.net
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: sg-httpbin-lite/1.0 Python/3.12.3
< Date: Sat, 10 Jan 2026 05:11:09 GMT
< Content-Length: 62
< Content-Type: text/html
##### snipped #####

    Lines beginning with > represent request headers sent by cURL, while lines beginning with < represent response headers returned by the server along the same connection.

  5. Store response headers for a real GET request in a file using --dump-header while discarding the body output. 
    $ curl --dump-header response-headers.txt --output /dev/null "http://api.example.net/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
##### snipped #####

    Option --dump-header writes all response headers into the specified file, and --output /dev/null suppresses the body so only header data is preserved.

  6. Inspect the stored header file to confirm the expected status line and key header fields. 
    $ head response-headers.txt
HTTP/1.1 200 OK
Server: sg-httpbin-lite/1.0 Python/3.12.3
Date: Sat, 10 Jan 2026 05:11:09 GMT
Content-Length: 62
Content-Type: text/html
##### snipped #####

    Successful inspection shows a valid status line such as HTTP/1.1 200 OK along with expected headers like Content-Type, Server, and any custom fields under investigation.