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 https://example.com/
   HTTP/1.1 200 OK
   Date: Mon, 01 Dec 2025 10:23:45 GMT
   Server: example-server
   Content-Type: text/html; charset=UTF-8
   Content-Length: 1256
   Connection: keep-alive
   ##### 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 https://example.com/old-path
   HTTP/1.1 301 Moved Permanently
   Location: https://example.com/new-path
   ##### snipped #####
   HTTP/2 200
   content-type: text/html; charset=UTF-8
   vary: Accept-Encoding
   ##### 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 https://api.example.com/status \
     --header 'Authorization: Bearer REPLACE_WITH_TOKEN' \
     --header 'Accept: application/json'
   HTTP/1.1 200 OK
   Date: Mon, 01 Dec 2025 10:30:12 GMT
   Content-Type: application/json
   Content-Length: 0
   ##### 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' \
     https://example.com/
   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 https://example.com/resource
   HTTP/1.1 405 Method Not Allowed
   Allow: GET, POST
   ##### snipped #####
   $ curl https://example.com/resource
   ##### snipped HTML body #####

   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.