How to view HTTP request headers with curl

Viewing the headers sent by curl confirms the exact HTTP request that left the command line before server logs, proxy rules, or application code are checked. The sent block shows the method, target host, default headers, and any extra header added with --header.

Use --verbose when the request itself needs inspection. In verbose output, > marks protocol lines sent by curl, < marks protocol lines received from the server, and * marks diagnostic messages from curl about DNS, TLS, protocol negotiation, and transfer state.

Response-header options solve a different job. --include, --show-headers, --dump-header, and --head show headers received from the server, while --verbose exposes the request headers that curl sent. Redact verbose output before sharing it because it can include Authorization headers, cookies, signed URLs, and other request secrets.

1. Run the request with --verbose and send the response body to /dev/null.

   $ curl --silent --show-error --verbose --output /dev/null https://example.com/
   * Host example.com:443 was resolved.
   ##### snipped #####
   * using HTTP/2
   * [HTTP/2] [1] [:method: GET]
   * [HTTP/2] [1] [:scheme: https]
   * [HTTP/2] [1] [:authority: example.com]
   * [HTTP/2] [1] [:path: /]
   * [HTTP/2] [1] [user-agent: curl/8.18.0]
   * [HTTP/2] [1] [accept: */*]
   ##### snipped #####
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.18.0
   > Accept: */*
   >
   * Request completely sent off
   ##### snipped #####
   < HTTP/2 200
   ##### snipped #####

   --silent hides the progress meter, --show-error keeps transfer errors visible, and --output /dev/null keeps the response body out of the header check.

2. Read only the lines that begin with > when checking what curl sent.

   The blank > line ends the request-header block. If a header is missing before that blank line, it was not sent in that request.

3. Add a request header with --header and confirm it appears in the sent block.

   $ curl --silent --show-error --verbose --header 'X-Debug-Id: sg-20260601-request-check' --output /dev/null https://example.com/
   ##### snipped #####
   * [HTTP/2] [1] [x-debug-id: sg-20260601-request-check]
   ##### snipped #####
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.18.0
   > Accept: */*
   > X-Debug-Id: sg-20260601-request-check
   >
   * Request completely sent off
   ##### snipped #####

   Use the same check for tenant, trace, feature flag, Accept, Content-Type, or Authorization headers. Replace real secret values with placeholders before saving or pasting the output.

   Related: How to override the Host header with cURL

4. Put --disable first when a local curl config file could be adding hidden request options.

   $ curl --disable --silent --show-error --verbose --output /dev/null https://example.com/
   * Host example.com:443 was resolved.
   ##### snipped #####
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.18.0
   > Accept: */*
   >
   * Request completely sent off
   ##### snipped #####

   --disable affects the curl config file only when it is the first command-line parameter. Place it before --silent, --verbose, and the URL when the output must reflect only the options shown in the command.

5. Inspect each sent block separately when redirects are followed.

   Headers supplied with --header can be reused on redirected requests. Avoid combining sensitive headers with --location unless the redirect targets are controlled and expected.

   Related: How to follow HTTP redirects with cURL