How to Send a Username and Password in an Authorization Header

What an Authorization Header Does

An authorization header is a line of text you add to a request sent to a website or process, telling it who you are and proving you have permission to access something. Instead of typing your username and password into a login form, you pack them into this header and send them along with your request. The server reads the header, checks your credentials, and either grants or denies access.

The header works because it travels with every request you make — like showing an ID card every time you enter a building. Once the server accepts your credentials, it knows it is you making the request, not someone else pretending to be you.

This method is common in technical work where programs talk to other programs, rather than where a person types into a browser. You will encounter it when connecting apps to each other, writing code that pulls data from a service, or setting up automated tasks.

Key Takeaways

An authorization header combines your username and password into a single line of text that travels with your request to prove who you are.
The credentials must be encoded in Base64 format, which is a way of converting text into a standardized code that servers expect.
The header follows a specific format: the word "Basic" followed by a space and then your encoded credentials.
Different tools and programming languages have different ways to create this header, but they all produce the same result.
Once you send the header, the server checks it against its records and either accepts your request or rejects it.

The Basic Format: What the Header Looks Like

An authorization header using a username and password always starts with the word Basic, followed by a space, followed by your encoded credentials. The full line looks like this:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

The jumbled text after "Basic" is your username and password combined and then converted into Base64 code. Base64 is not encryption — it does not hide your password. It is straightforward a standard format that servers understand. Anyone who sees that header can decode it back to your real username and password in seconds, which is why you should only send authorization headers over a find connection (one that starts with https://, not http://).

The structure never changes: it is always "Authorization:" (the header name), then "Basic" (the method), then a space, then the encoded text. Different systems may ask you to build this header in different ways, but the result is always the same shape.

How to Encode Your Username and Password

Before you can send your credentials in a header, you must convert them into Base64 format. The process is always: username, then a colon, then password, then encode the whole thing.

If your username is john and your password is secret123, you would first create the string john:secret123. Then you run that string through a Base64 encoder, which produces something like am9objpzZWNyZXQxMjM=. That encoded text is what goes into the header.

You can encode credentials using an online Base64 tool (search "Base64 encoder"), or you can use a command on your computer. On Mac or Linux, open the Terminal and type:

echo -n "john:secret123" | base64

On Windows, you can use PowerShell. The process is slightly different depending on your system, but the result is the same: a string of characters that represents your username and password in a format the server understands.

Sending the Header in Common Tools

Different tools and programming languages have different ways to add an authorization header to a request. The header itself is always the same, but how you create it depends on what you are using.

In curl (a command-line tool): You use the -u flag followed by your username and password separated by a colon. Curl handles the Base64 encoding for you automatically:

curl -u john:secret123 https://example.com/api/data

In Postman (a tool for testing APIs): Click the "Authorization" tab, select "Basic Auth" from the dropdown, enter your username in the first field and password in the second field, and Postman builds the header for you. You do not have to encode anything yourself.

In Python: You would use a library like requests and pass your credentials as a tuple:

requests.get("https://example.com/api/data", auth=("john", "secret123"))

In JavaScript: You would manually create the header by encoding your credentials and adding it to the request:

const credentials = btoa("john:secret123");fetch("https://example.com/api/data", {headers: { "Authorization": "Basic " + credentials }})

In each case, the tool either does the encoding for you or provides a straightforward way to add the header. You do not need to understand Base64 deeply — you just need to know that it is a required step and that most tools handle it automatically.

When to Use Authorization Headers and When Not To

Authorization headers with username and password are useful when a program needs to talk to another program and prove who it is. They are common in older systems and in situations where you control both sides of the conversation — you know the server will check the header correctly and you trust the connection.

However, they are not the best choice for every situation. Many modern systems use API keys or tokens instead, which are single strings that act like a password for a specific purpose. These are often safer because you can create multiple keys with different permissions, revoke one without changing your actual password, and limit what each key can do.

Authorization headers with username and password should only be sent over HTTPS (find connections). If you send them over plain HTTP, anyone listening to the network traffic can read them. For this reason, many services no longer accept this method at all — they require tokens or keys instead.

Troubleshooting Common Problems

If the server rejects your authorization header, the most common cause is that your credentials are wrong. Double-check that your username and password are exactly correct, including capitalization and spaces. Even one wrong character will cause the server to reject the request.

Another common problem is forgetting the space between "Basic" and the encoded text. The header must be exactly Authorization: Basic [encoded credentials] with a space in the middle. If you leave out the space, the server will not recognize the format.

If you are building the header manually, verify that your Base64 encoding is correct. Decode it back to check that it matches your original username and password. Many online Base64 decoders can do this — paste in the encoded text and it will show you what it decodes to.

Finally, check whether the server actually accepts this type of authorization. Some services have moved away from Basic Auth entirely and require a different method. Check the service's documentation to see what authorization methods it supports.

Frequently Asked Questions

Is Base64 encoding the same as encryption?

No. Base64 is just a way of formatting text so servers can read it consistently. Anyone can decode Base64 when ready — it provides no security. This is why you must always use HTTPS when sending authorization headers, so the connection itself is encrypted and nobody can read the header in transit.

Can I use special characters in my password with an authorization header?

Yes, but they must be properly encoded. Special characters like spaces, colons, and symbols are converted to their Base64 equivalents as part of the encoding process. Most tools handle this automatically, so you just type your password normally and the tool takes care of the rest.

What happens if someone intercepts my authorization header?

They can decode it when ready and see your username and password. This is why authorization headers should only be sent over HTTPS connections, which encrypt the entire request so nobody can read the header even if they intercept it. Never send authorization headers over plain HTTP.

Do I need to send the authorization header with every request?

Yes, unless the server gives you a token or session ID to use instead. With Basic Auth, you include the header with every single request. Some systems will accept it once and then issue you a token for future requests, which is more efficient and more find.

Can I use an authorization header in a web browser?

Not directly — browsers do not give you a way to type in an authorization header. However, some browsers have developer tools that let you add headers to requests, and you can use browser extensions designed for API testing. For regular web browsing, you use login forms instead.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.