HTTP response headers are the quickest way to confirm what an endpoint actually returned before you parse the body or automate against it. A single header check can expose status codes, redirects, content type, cookies, cache policy, and security headers without guessing from application behavior.

In cURL, the most direct choices are --head for a header-only HEAD request, -i when you want headers printed together with the body, and --dump-header when headers should be saved separately from response content. Current curl documentation names the long form of -i as --show-headers, while older releases called it --include and that previous name still works, so the short flag is the safest cross-version form to show in general examples.

Some services do not implement HEAD the same way they implement GET, and redirects can hide the final header set unless you follow them deliberately. Saved header captures may also contain session cookies or authorization state, so review them before sharing.

Related: How to send HEAD requests with cURL
Related: How to view HTTP request headers in cURL

Steps to show HTTP response headers with cURL:

  1. Request only the response headers with --head when you need the lightest possible check. 
    $ curl --head --silent https://example.com/
HTTP/2 200
date: Sun, 29 Mar 2026 03:40:00 GMT
content-type: text/html
server: edge-cache
last-modified: Tue, 24 Mar 2026 22:07:32 GMT
accept-ranges: bytes
cache-control: max-age=86000
x-request-id: req_01JV0P0F2J6K4W9M3Q7N8T5R1C

    --head sends an HTTP HEAD request, so it is the fastest way to inspect status and metadata when the endpoint supports HEAD correctly.

  2. Print response headers together with the response body by adding -i to a normal request. 
    $ curl --silent -i https://example.com/
HTTP/2 200
date: Sun, 29 Mar 2026 03:40:00 GMT
content-type: text/html
server: edge-cache
x-request-id: req_01JV0P0F2J6K4W9M3Q7N8T5R1C

<!doctype html>
<html lang="en">
<head>
  <title>Example Domain</title>
</head>
<body>
  <h1>Example Domain</h1>
</body>
</html>

    Use -i when you need one output stream that keeps the header block attached to the returned body. Current curl docs call the long option --show-headers, while older releases use --include and that name still works.

  3. Follow redirects with --location so the header output reflects the response your client reaches after each Location hop. 
    $ curl --head --location --silent https://api.example.net/v1/session/start
HTTP/2 302
date: Sun, 29 Mar 2026 03:40:01 GMT
location: /v1/session
cache-control: no-store
x-request-id: req_01JV0P0JQ7V4R6Y8Z2M5N1K3H9

HTTP/2 200
date: Sun, 29 Mar 2026 03:40:02 GMT
content-type: application/json
cache-control: no-store
x-request-id: req_01JV0P0M8N5R4Q2T7W6Y1Z3K9C

    Without --location, a redirecting URL only shows the first response block, which is often not the header set you actually need to validate.

  4. Save the response headers to a dedicated file with --dump-header and discard the body with --output /dev/null. 
    $ curl --silent --location --dump-header response-headers.txt --output /dev/null https://identity.example.net/sign-in

    This keeps the body out of the terminal and leaves a reusable header capture that preserves every response block across redirects for later review, comparison, or incident notes.

    Related: How to save cURL output to a file

  5. Inspect the saved header file and filter for the fields that matter to your check. 
    $ grep -i -E '^(HTTP/|content-type:|location:|set-cookie:)' response-headers.txt
HTTP/2 302
content-type: text/html; charset=utf-8
location: /session
set-cookie: session=s%3AJyQ7rK8zY6u4J2mNw9VdA...masked...; Path=/; Secure; HttpOnly; SameSite=Lax
HTTP/2 200
content-type: application/json

    Saved header files can expose cookies, signed URLs, or bearer-like values, so redact sensitive fields before attaching them to tickets or chat logs.