The X-Authorization header is how a website's server checks that you are who you say you are when you make a request

When your browser or app sends information to a website's server, that server needs to know whether to trust the request. The X-Authorization header is one way to prove your identity — it's a line of text that travels with your request and contains a token or credential that the server recognizes. Think of it like showing an ID card at a door: the header is the card, and the server is the person checking it.

The header gets its name from the "X-" prefix, which in technical standards means "custom" or "non-standard." This matters because there is also a standard Authorization header that does the same job. Some websites and apps use the standard version; others use X-Authorization instead. Both work the same way — they carry proof that you are allowed to access what you are asking for.

You never see this header in your browser's address bar or in normal web pages. It travels invisibly between your device and the server, included automatically by your browser or app. But if you open your browser's developer tools (usually by pressing F12), you can watch these headers go back and forth.

Key Takeaways

  • The X-Authorization header carries a token or credential that proves your identity to a website's server without requiring you to send your password with every request.
  • It travels invisibly with every request your browser or app makes, included automatically and checked by the server before it sends back any data.
  • The "X-" prefix means the header is custom rather than part of the official HTTP standard, though it works the same way as the standard Authorization header.
  • Different websites format the token differently — some use "Bearer" tokens, others use API keys or session IDs, but the purpose is always to verify who you are.
  • You can see these headers in your browser's developer tools, which is useful for troubleshooting when a website says you are not logged in even though you are.

How the header proves your identity without sending your password

When you log into a website, you send your username and password once. The server checks them, and if they are correct, it creates a token — a long string of characters that represents your logged-in session. The server remembers this token and associates it with your account.

From that point on, instead of sending your password with every single request, your browser or app sends the token in the X-Authorization header. The server looks at the token, recognizes it as belonging to you, and processes your request. This is safer than sending your password repeatedly because even if someone intercepts the token, it expires after a set time and cannot be used to change your password.

The token format varies by website. Some use "Bearer" tokens (the header looks like "X-Authorization: Bearer abc123xyz"), others use "Token" or just the raw token string. The format does not matter to how it works — the server knows what format to expect and checks whether the token is valid.

The difference between X-Authorization and the standard Authorization header

HTTP, the language that browsers and servers use to talk to each other, has an official Authorization header defined in the standards. This header does exactly what X-Authorization does — it carries credentials to prove your identity.

Some websites and apps use the standard Authorization header. Others use X-Authorization instead, usually because their code was written before the standard was widely adopted, or because they needed a custom format that the standard header did not support. There is no technical reason one is better than the other — it is just a choice the developer made.

If you are building an app or website, the standard Authorization header is the recommended choice because other developers will expect it. But if you are using a website or app that uses X-Authorization, it works exactly the same way.

Where you see X-Authorization in real websites and apps

Many modern web applications use X-Authorization, especially APIs (the systems that apps use to talk to servers). If you use a mobile app that logs you in, that app is probably sending an X-Authorization header with every request it makes to the company's servers.

Some examples include certain banking apps, social media platforms, and cloud storage services. When you open the app and it shows your account information without asking you to log in again, the app is using a stored token in the X-Authorization header to prove you are still logged in.

You also see it in web-based tools — if you use a project management app, design tool, or email service in your browser, and you stay logged in across multiple pages, that is the X-Authorization header at work. The server trusts the token, so it does not make you log in again.

What happens when the X-Authorization header is missing or invalid

If your browser or app does not send the X-Authorization header, or if the token in it has expired, the server will reject your request. You will usually see an error like "Unauthorized" or "401" (which is the technical code for "I do not recognize you").

This is why you sometimes get logged out of a website even though you did not click a logout button. The token expired, your browser did not send a valid X-Authorization header, and the server refused to process your request. Logging in again creates a new token.

If you are using an app and it keeps saying you are not logged in, the problem is often that the X-Authorization header is not being sent correctly. This can happen if the app crashed, if your internet connection dropped, or if the token was deleted. Logging out and back in usually fixes it by creating a new token.

How to see X-Authorization headers in your browser

If you want to watch these headers in action, open your browser's developer tools. In Chrome, Firefox, Safari, and Edge, press F12 (or Cmd+Option+I on Mac). Go to the Network tab, then reload the page or perform an action like clicking a button.

You will see a list of requests your browser made. Click on any request to see its details. Look for a "Headers" or "Request Headers" section. Scroll down and you may see an Authorization header or X-Authorization header listed. It will show something like "X-Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." — that long string is the token.

This is a useful way to troubleshoot if a website is not working correctly. If you are logged in but the X-Authorization header is not being sent, that is why the website is not recognizing you. If the header is being sent but the server is still rejecting it, the token may have expired.

Security considerations when using X-Authorization

The X-Authorization header should only be sent over HTTPS, which encrypts the connection between your browser and the server. If a website sends it over plain HTTP, anyone on the same network could intercept the token and use it to access your account.

Legitimate websites always use HTTPS (you can see the lock icon in your address bar). If a website asks you to log in but does not use HTTPS, do not enter your password — it is not safe.

Tokens should also expire after a set time. A token that works forever is a security risk because if someone steals it, they can use it indefinitely. Good websites create tokens that expire after hours or days, forcing you to log in again periodically. Some also let you manually revoke a token if you think it has been compromised.

Frequently Asked Questions

Can someone steal my X-Authorization token?

Yes, if they intercept the connection between your browser and the server. This is why websites must use HTTPS to encrypt the connection. If you use public WiFi, use a VPN to add an extra layer of encryption. Tokens also expire, so even if someone steals one, it will stop working after a few hours or days.

Why do some websites use X-Authorization and others use Authorization?

It is a developer choice. The standard Authorization header is recommended, but X-Authorization works the same way. Some older code uses X-Authorization because it was written before the standard was widely adopted. Both are valid; the difference is just naming.

What does "Bearer" mean in the X-Authorization header?

Bearer is a format that tells the server what type of token is being sent. It means "I am bearing (carrying) a token that proves who I am." Other formats exist, but Bearer is the most common. The server knows how to read it and extract the actual token from the header.

If I clear my browser cookies, will X-Authorization stop working?

It depends on how the website stores the token. Some websites store the token in a cookie, so clearing cookies removes it. Others store it in browser storage (a different system), so clearing cookies does not affect it. Either way, you will be logged out and will need to log in again to get a new token.

Why do I get logged out even though I did not click logout?

The X-Authorization token expired. Websites set tokens to expire after a certain time for security reasons. When the token expires, the server stops recognizing it, and you are logged out. Logging in again creates a new token with a fresh expiration time.