How to Send Basic Auth Credentials with curl

Pass the credentials as username:password after -u:

curl -u myuser:mypassword https://example.com/api/data

curl encodes them and sends Authorization: Basic bXl1c2VyOm15cGFzc3dvcmQ=. --user is the long form of -u and behaves identically. Basic is curl's default auth scheme, so you don't need --basic.

Hide the password from your shell history. Give only the username and curl will prompt for the password interactively (it won't be echoed or stored):

curl -u myuser https://example.com/api/data
# Enter host password for user 'myuser':

If you already have the Base64 token (or want full control), skip -u and send the header yourself with -H:

# Build the token, then send it
TOKEN=$(printf 'myuser:mypassword' | base64)
curl -H "Authorization: Basic $TOKEN" https://example.com/api/data

This is exactly what -u produces — useful when the token is supplied by another system, or when you're translating a curl command into application code.

If the username or password contains shell-special characters ($, !, spaces, @), wrap the pair in single quotes so your shell doesn't expand them:

curl -u 'new_user:my$ecret p@ss!' https://example.com

If the password itself contains a colon, only the first colon is treated as the separator, so a colon in the password is fine — but a colon in the username is not allowed by the Basic Auth spec.

To keep credentials out of the command line entirely, store them in a ~/.netrc file and let curl read them with -n / --netrc:

# ~/.netrc  (chmod 600 it)
machine example.com login myuser password mypassword

curl -n https://example.com/api/data
# or point at a specific file:
curl --netrc-file ./secrets.netrc https://example.com/api/data

Basic Auth is encoded, not encrypted
The Base64 token is trivially reversible. Over plain http:// anyone on the network can read your password. Always use an https:// endpoint so TLS encrypts the header in transit.

For scraping behind a login, Basic Auth is rarely the blocker — anti-bot systems care about your IP reputation and browser fingerprint, not your auth header. If an authenticated endpoint returns 403 or 429 even with correct credentials, the fix is proxies and a real browser profile, not the auth flag.