How to set custom headers in wget requests

HTTP headers carry metadata that controls how web servers interpret and respond to requests, including authentication tokens, language hints, and accepted formats. Adjusting these headers in command-line tools makes it possible to interact with APIs, replay browser-like traffic, and reproduce specific client behaviors for debugging or automation.

GNU wget sends a standard set of headers for HTTP and HTTPS requests and exposes the --header option to add or override individual fields. Repeating --header attaches multiple headers, enabling custom User-Agent strings, tailored Accept types, and correlation identifiers without rewriting server configuration or changing application code.

Because headers often embed sensitive values such as API keys or bearer tokens, misuse can leak secrets into shell history, process listings, and shared scripts. A terminal with wget installed and network access is assumed, and inspection with debug output provides a reliable way to confirm exactly which headers are transmitted before requests reach external services.

1. Check the installed wget version in a terminal to confirm availability.

   $ wget --version
   GNU Wget 1.21.3 built on linux-gnu.
   ##### snipped #####

2. Send a request with a single custom header using the --header option.

   $ wget --header="User-Agent: WgetCustomClient/1.0" https://example.com/api/status
   --2025-12-08 10:30:00--  https://example.com/api/status
   Resolving example.com (example.com)... 93.184.216.34
   Connecting to example.com (93.184.216.34):443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 532 [application/json]
   Saving to: ‘status.json’
   ##### snipped #####

   Quoting the entire header value ensures spaces, slashes, and other punctuation in User-Agent or similar fields reach the server unchanged.

3. Attach multiple custom headers by repeating the --header option in the same command.

   $ wget \
     --header="User-Agent: WgetCustomClient/1.0" \
     --header="Accept: application/json" \
     --header="X-Trace-Id: demo-1234" \
     https://example.com/api/status
   --2025-12-08 10:31:12--  https://example.com/api/status
   Resolving example.com (example.com)... 93.184.216.34
   Connecting to example.com (93.184.216.34):443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 532 [application/json]
   Saving to: ‘status.json’
   ##### snipped #####

   Repeating --header appends multiple fields to the request so that client identity, accepted formats, and tracing data travel together.

4. Include an Authorization header when an API expects a bearer token or similar credential in the request.

   $ wget \
     --header="Authorization: Bearer abc123-example-token" \
     https://example.com/api/secure-resource
   --2025-12-08 10:32:05--  https://example.com/api/secure-resource
   Resolving example.com (example.com)... 93.184.216.34
   Connecting to example.com (93.184.216.34):443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 1024 [application/json]
   Saving to: ‘secure-resource.json’
   ##### snipped #####

   Embedding real secrets in command lines exposes them to shell history and process listings, which can leak credentials on shared or multi-user systems; prefer environment variables or configuration files that are not committed to version control.

5. Inspect the full request headers by enabling debug output for a sample call.

   $ wget \
     --header="User-Agent: WgetCustomClient/1.0" \
     --header="Accept: application/json" \
     --debug \
     https://example.com/api/status
   DEBUG output created by Wget 1.21.3 on linux-gnu.
   ##### snipped #####
   ---request begin---
   GET /api/status HTTP/1.1
   User-Agent: WgetCustomClient/1.0
   Accept: application/json
   Host: example.com
   Connection: Keep-Alive
   ---request end---
   ##### snipped #####

   --debug shows the exact HTTP request lines, including all custom headers, which helps confirm the client side of an integration before investigating server-side issues.

6. Verify that specific custom headers appear in the debug stream by filtering the output.

   $ wget \
     --header="User-Agent: WgetCustomClient/1.0" \
     --header="X-Trace-Id: demo-1234" \
     --debug \
     https://example.com/api/status 2>&1 | grep -E 'User-Agent|X-Trace-Id'
   User-Agent: WgetCustomClient/1.0
   X-Trace-Id: demo-1234

   Presence of the expected header lines in filtered debug output, combined with a normal HTTP status such as 200 OK, confirms that custom headers left the host and were accepted by the remote server.