How to view HTTP request headers in cURL

Inspecting HTTP request headers produced by curl reveals exactly what information is transmitted to a web server, including the method, path, host, user agent, and any authentication or tracing fields. Direct visibility into these headers supports HTTP API debugging, security reviews, and protocol troubleshooting.

The curl client builds an HTTP request from the URL, command-line options, and environment, then writes the response body to standard output. With the --verbose flag, curl additionally prints connection progress and raw HTTP headers to the error stream, enabling shell tools to filter out only the client-side request lines.

Verbose traces and header logs may contain secrets such as bearer tokens, API keys, or cookies, so generated output must be stored with care and redacted before sharing. The examples below assume a POSIX-style shell and standard curl builds, but the same options function similarly on Linux, macOS, and recent Windows terminals.

1. Run a verbose HTTP request to show connection progress along with both request and response headers.

   $ curl "https://example.com" --verbose
   * Host example.com:443 was resolved.
   * IPv6: (none)
   * IPv4: 172.17.0.5
   *   Trying 172.17.0.5:443...
   * Connected to example.com (172.17.0.5) port 443
   * ALPN: curl offers h2,http/1.1
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.5.0
   > Accept: */*
   > 
   < HTTP/2 200 
   < alt-svc: h3=":443"; ma=2592000
   < content-type: text/html
   < date: Sun, 21 Dec 2025 11:27:49 GMT
   < last-modified: Sun, 21 Dec 2025 07:25:29 GMT
   < server: SimpleHTTP/0.6 Python/3.12.12
   < content-length: 1243
   ##### snipped #####

   Lines beginning with > are HTTP request headers from the client, and lines beginning with < are response headers from the server.

2. Pipe verbose output through grep to display only the lines that contain request headers.

   $ curl "https://example.com" --verbose 2>&1 | grep '^>'
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.5.0
   > Accept: */*
   > 

   Redirection with 2>&1 merges standard error into standard output so that grep can filter all verbose lines in a single stream.

3. Add a custom header and confirm its presence in the filtered request header list.

   $ curl "https://example.com" --verbose --header "X-Debug: 1" 2>&1 | grep '^>'
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.5.0
   > Accept: */*
   > X-Debug: 1
   > 

   Custom headers such as X-Debug help correlate individual requests with entries in server logs or tracing systems.

4. Capture verbose diagnostics and the response body in separate files for later inspection.

   $ curl "https://example.com" --verbose --output ./example.html 2> ./example-verbose.log

   Storing verbose output in a dedicated log file preserves all HTTP headers and connection details without cluttering the terminal.

5. Inspect the saved verbose log to verify that all expected request headers were transmitted.

   $ grep '^>' ./example-verbose.log
   > GET / HTTP/2
   > Host: example.com
   > User-Agent: curl/8.5.0
   > Accept: */*
   > 

   Presence of each header line in the log confirms that curl sent those fields to the remote HTTP server.

6. Remove or mask sensitive headers before sharing saved logs with other parties.

   $ sed -E 's/^(> Authorization:).*/\1 ***REDACTED***/' ./example-verbose.log > ./example-verbose-redacted.log

   Request headers can include secrets in Authorization or cookie fields, so any shared logs must hide values that could grant access to protected services.