How to send HEAD requests with cURL

HEAD requests focus on response headers, making them useful for checking status codes, redirects, content types, and caching behavior without downloading full response bodies. Using cURL for HEAD traffic keeps monitoring, health checks, and diagnostics efficient while still exposing how an HTTP endpoint behaves under real conditions.

The HTTP HEAD method returns the same headers that a comparable GET request would produce but omits the payload. With the --head option or its short form -I, cURL switches to the HEAD method for HTTP and HTTPS URLs and prints the response headers to standard output, which fits both interactive use and automation in scripts or CI pipelines.

Some endpoints implement HEAD differently from GET or disable it entirely, which can result in 403 or 405 responses even when GET still works. Combining HEAD with authentication headers or cache-sensitive URLs requires care to avoid leaking secrets, misreading cache directives, or triggering unintended rate limits, so testing is safest against idempotent status and metadata endpoints.

1. Send a basic HEAD request to inspect response headers for a public URL.

   $ curl --head --silent 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:17:25 GMT
   Content-Length: 62
   Content-Type: text/html
   ##### snipped #####

   The --head option switches cURL to the HEAD method and prints only response headers; the short form -I behaves the same way.

2. Follow redirects during a HEAD request to see both intermediate and final response headers.

   $ curl --head --location --silent http://api.example.net/redirect/1
   HTTP/1.1 302 Found
   Server: sg-httpbin-lite/1.0 Python/3.12.3
   Date: Sat, 10 Jan 2026 05:17:25 GMT
   Location: /redirect/0
   Content-Length: 0
   ##### snipped #####
   HTTP/1.1 302 Found
   Server: sg-httpbin-lite/1.0 Python/3.12.3
   Date: Sat, 10 Jan 2026 05:17:25 GMT
   Location: /get
   Content-Length: 0
   ##### snipped #####
   HTTP/1.1 200 OK
   Server: sg-httpbin-lite/1.0 Python/3.12.3
   Date: Sat, 10 Jan 2026 05:17:25 GMT
   Content-Length: 229
   Content-Type: application/json
   ##### snipped #####

   The --location option makes cURL follow redirect responses so the last header block corresponds to the final URL.

3. Attach authentication or other custom headers to a HEAD request when checking protected status endpoints.

   $ curl --head --silent --cacert /work/docker/certs/ca.crt https://api.example.net/bearer/protected \
     --header 'Authorization: Bearer access-demo-token' \
     --header 'Accept: application/json'
   HTTP/1.1 200 OK
   Server: sg-httpbin-lite/1.0 Python/3.12.3
   Date: Sat, 10 Jan 2026 05:17:25 GMT
   Content-Length: 59
   Content-Type: application/json
   ##### snipped #####

   Transmitting credentials or tokens over plain http:// allows interception by intermediaries; prefer https:// and revoke or rotate secrets if compromise is suspected.

4. Measure transfer size for a HEAD request by discarding output and printing status information.

   $ curl --head --silent --output /dev/null \
     --write-out 'Status: %{http_code}\nBody bytes: %{size_download}\n' \
     http://api.example.net/
   Status: 200
   Body bytes: 0

   Success indicators include a 2xx or 3xx status and Body bytes: 0, confirming that only headers were transferred for the HEAD request.

5. Check for HEAD support by sending a HEAD request to the resource.

   $ curl --head --silent http://api.example.net/no-head
   HTTP/1.1 405 Method Not Allowed
   Server: sg-httpbin-lite/1.0 Python/3.12.3
   Date: Sat, 10 Jan 2026 05:17:25 GMT
   Allow: GET
   Content-Length: 0
   ##### snipped #####
   $ curl --silent http://api.example.net/no-head | head -n 4
   {
     "status": "ok"
   }

   A 405 response with an Allow header shows that the resource does not accept the HEAD method even though GET may still succeed, which is important when designing monitoring checks.