How to change the user agent string in cURL

Changing the User-Agent header in cURL helps reproduce browser-specific responses, confirm what an API gateway or WAF sees, and explain why the same URL behaves differently across clients. The quickest path is usually to send one request with a temporary override, confirm the header that left the client, and keep the default identifier unchanged unless every future request needs the same value.

By default, cURL sends its own identifier, such as curl/<version>. Current curl behavior exposes a dedicated -A or --user-agent option for per-request overrides, while a user-agent entry in ~/.curlrc changes the default used by later commands. Verbose mode prints the outbound request block, which makes it easy to confirm the exact header before checking server-side logs.

Local curl config can already inject flags, so a clean test often starts with --disable to ignore the default config file for that one command. Some services also use User-Agent for bot detection, rate limits, or policy enforcement, so treat header changes as controlled testing rather than a way to disguise automated traffic in production.

1. Check the default User-Agent value with a clean request before overriding anything.

   $ curl --disable --silent --show-error https://httpbingo.org/user-agent
   {
     "user-agent": "curl/8.7.1"
   }

   Success is visible when the response shows the built-in cURL identifier rather than a value injected by local config.

2. Override the header for one request with --user-agent when only that invocation should change.

   $ curl --disable --silent --show-error \
     --user-agent 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36' \
     https://httpbingo.org/user-agent
   {
     "user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36"
   }

   The dedicated --user-agent option is the clearest choice when the request only needs a different User-Agent value.

3. Inspect the outbound request headers with --verbose when the exact wire-level value needs to be confirmed locally.

   $ curl --disable --silent --show-error --verbose \
     --output /dev/null \
     --user-agent 'ExampleInventoryClient/2026.03' \
     https://httpbingo.org/user-agent 2>&1 | grep '^>'
   > GET /user-agent HTTP/2
   > Host: httpbingo.org
   > User-Agent: ExampleInventoryClient/2026.03
   > Accept: */*

   The > lines are the headers sent by cURL, which makes this the fastest client-side proof before checking upstream logs.

4. Set the header with --header when the request is already being built from raw custom headers.

   $ curl --disable --silent --show-error \
     --header 'User-Agent: ExampleInventoryClient/2026.03' \
     --header 'X-Request-Profile: diagnostics' \
     https://httpbingo.org/anything
   {
     "args": {},
     "headers": {
       "Accept": [
         "*/*"
       ],
       "Host": [
         "httpbingo.org"
       ],
       "User-Agent": [
         "ExampleInventoryClient/2026.03"
       ],
       "X-Request-Profile": [
         "diagnostics"
       ]
     },
     "method": "GET",
     "url": "https://httpbingo.org/anything"
   }

   Public echo services often add proxy metadata of their own, so focus on the custom User-Agent and X-Request-Profile values. Prefer --user-agent when that is the only header being changed, and use --header when the request is already managed as a manual header set.

5. Add or update a user-agent entry in ~/.curlrc when future cURL commands should use the same default.

   user-agent = "ExampleInventoryClient/2026.03"

   If ~/.curlrc already contains a user-agent line, replace the existing entry instead of stacking conflicting defaults. This setting affects later cURL commands until it is removed or overridden on the command line.

6. Run a normal request without --disable to confirm that the persistent default is now active.

   $ curl --silent --show-error https://httpbingo.org/user-agent
   {
     "user-agent": "ExampleInventoryClient/2026.03"
   }

   Success is visible when the response shows the configured default from ~/.curlrc rather than the built-in curl/... value.