cURL basic auth: -u, -U and proxy logins

curl logs in with two options. -u user:password sends a login to the site, -U user:password sends one to the proxy. Both are Basic authentication by default: the username and password, joined by a colon and encoded in base64.

We tested both with curl 8.5.0 on 11 October 2026, against httpbin.org and a small proxy of our own that logs everything it receives. The proxy saw its own login. It never saw the site's.

How do you use basic auth with curl?

Put the login after -u:

curl -u demo:secret https://httpbin.org/basic-auth/demo/secret

The answer was {"authenticated":true,"user":"demo"} with status 200. The same command with a wrong password got 401. You can also put the login in the address, as https://demo:secret@httpbin.org/..., which got 200 as well.

The standard for Basic, RFC 7617, says the client "constructs the user-pass by concatenating the user-id, a single colon (':') character, and the password". Then it encodes that in base64 and sends it in an Authorization header. curl's manual adds a rule for odd passwords: "The username and passwords are split up on the first colon". A colon can sit in the password, but not in the username.

Is basic auth safe?

Only inside HTTPS. Base64 is an encoding that anyone can reverse. We printed the header curl sent and decoded it:

$ curl -v -u demo:secret https://httpbin.org/basic-auth/demo/secret 2>&1 | grep Authorization
> Authorization: Basic ZGVtbzpzZWNyZXQ=
$ echo ZGVtbzpzZWNyZXQ= | base64 -d
demo:secret

RFC 7617 says so itself: the scheme "is not considered to be a secure method of user authentication unless used in conjunction with some external secure system such as TLS". The reason it gives is plain: "the user-id and password are passed over the network as cleartext". Over https:// the header travels encrypted. Over http://, anyone on the path can read it.

How do you keep the password out of your history?

A password typed after -u ends up in your shell's history. There are two cleaner ways:

Let curl ask. The manual: "If you specify only the username, curl prompts for a password." So -u demo makes curl ask.
Use a .netrc file. --netrc makes curl "scan the .netrc file in the user's home directory for login name and password".

Watch the colon. In our test, -u demo: with a colon did not ask anything. It sent demo: with an empty password right away and got 401. Only -u demo, without the colon, printed Enter host password for user 'demo':.

What if the server wants Digest?

Some servers do not accept Basic. httpbin's Digest page refused plain -u with 401, and accepted the same login with --digest:

curl --digest -u demo:secret https://httpbin.org/digest-auth/auth/demo/secret

The manual explains the point of it: Digest "avoids sending the password over the wire in clear text". RFC 7616 describes it as "a simple challenge-response paradigm": the server sends a one-time value, and the client answers with a hash instead of the password. If you do not know which scheme a server wants, --anyauth finds out. It sends a first request, reads the answer, and uses "the most secure one the remote site claims to support", at the cost of an extra round trip.

How do you log in to a proxy?

With -U, the proxy's own login. A proxy that wants a login and does not get one answers 407. RFC 9110 says that code "indicates that the client needs to authenticate itself in order to use a proxy for this request". The client then answers with a Proxy-Authorization header. We ran both cases through our own proxy:

Terminal output: -u with the right and the wrong password, the Authorization header decoded with base64 -d, Digest with and without --digest, the proxy answering 407 without -U and 200 with it, and the proxy's log: the CONNECT line with Proxy-Authorization, and no Authorization header — Our own capture, 11 October 2026: auth_test.sh with curl 8.5.0 on our server

Without -U, the tunnel never opened: the proxy answered 407. With -U proxyuser:proxypass, it opened, and the site's own login with -u went through as well. Our residential proxies take their login the same way, with -U.

What does the proxy see?

Each login goes to a different place. Our proxy wrote down everything it received:

Diagram: curl sends CONNECT with Proxy-Authorization to the proxy, which reads the proxy login; the site's Authorization header travels inside the TLS tunnel through the proxy, and only the site reads it — Diagram: HProxy, from our test of 11 October 2026

The log showed CONNECT httpbin.org:443, the Proxy-Authorization header with the proxy's login, the User-Agent, and nothing else. The site's Authorization header never appeared. It travelled inside the tunnel, where the proxy only relays encrypted bytes. RFC 9110 calls that "blind forwarding of data".

One part stays exposed. The CONNECT line, with the proxy login in it, goes to the proxy before any encryption starts. With a plain http:// proxy address, anyone between you and the proxy can read and decode it. We showed the same CONNECT line in clear in how to hide your IP address.

What this page could not check

One machine with curl 8.5.0, httpbin.org as the site, and our own small proxy, which only logs and relays. Real proxies may log more.
We did not test NTLM, Negotiate or bearer tokens, or proxies reached over https://.
Whether a given proxy provider keeps logs is not something a test from outside can see.
We will run the test again with the current curl by 11 January 2027.

Sources

RFC 7617, The 'Basic' HTTP Authentication Scheme, IETF, September 2015: rfc-editor.org.
RFC 7616, HTTP Digest Access Authentication, IETF, September 2015: rfc-editor.org.
RFC 9110, HTTP Semantics, 407, Proxy-Authorization and CONNECT, IETF, June 2022: rfc-editor.org.
curl, man page, -u, -U, --digest, --anyauth and --netrc, read 11 October 2026: curl.se.
Our own test on our server, 11 October 2026, 09:03 UTC: auth_test.sh and authproxy.py with curl 8.5.0, and the -u prompt test at about 09:06 UTC.

Frequently asked questions

How do I use basic auth with curl?

Add -u user:password. curl turns it into an Authorization header: the two joined by a colon and encoded in base64. In our test the right password got 200 and a wrong one 401.

Is curl basic auth secure?

Only over HTTPS. Base64 is an encoding, not encryption: base64 -d turned the header from our test straight back into the password. The standard calls Basic insecure without TLS for that reason.

What is the difference between -u and -U in curl?

-u logs in to the site, -U logs in to the proxy. A site that wants a login answers 401 without -u, and a proxy that wants one answers 407 without -U.

How do I keep my password off the command line?

Give only the username, as -u user, and curl asks for the password. Or keep the login in a .netrc file and add --netrc. Note that -u user: with a colon does not ask: it sends an empty password.

Can the proxy see my site password?

Not over HTTPS. Our logging proxy saw its own login on the CONNECT line, but the site's Authorization header travelled inside the encrypted tunnel and never reached its log.

Why does the server answer 401 although the password is right?

It may want another scheme. A Digest page refused plain -u in our test and accepted --digest. --anyauth asks the server first and picks the strongest scheme it offers.

cURL basic auth: -u, headers and proxy authentication