What Is a 401 Unauthorized Error?
A 401 Unauthorized error is an HTTP status code that means the server requires valid authentication before it will serve the requested resource, and you either supplied none or supplied credentials it rejected. In plain terms, the page is asking you to log in. It differs from a 403 Forbidden, where you are recognized but still barred. Common triggers include expired login sessions, wrong passwords, missing or invalid API keys, and password-protected pages. Because it is about identity, the fix is almost always providing correct, current credentials.
- Status class
- 4xx client error; authentication is required and missing or invalid (MDN Web Docs)
- Meaning
- Request lacks valid authentication credentials for the resource (RFC 9110)
- Paired header
- Server must send a WWW-Authenticate header with a 401 (RFC 9110)
- Key difference
- 401 means log in first; 403 means logged in but still forbidden
- Common triggers
- Expired sessions, wrong passwords, invalid API keys, protected pages
What a 401 Unauthorized error means #
A 401 Unauthorized error is the server telling you it will not serve the requested page until you prove who you are with valid credentials. You have either sent no authentication at all or sent details the server rejected, such as an expired session or a wrong password. The HTTP specification requires that a 401 response include a WWW-Authenticate header describing how to authenticate, which is what makes the browser prompt you to log in (RFC 9110). For most users this appears as a login pop-up or a redirect to a sign-in page. For developers it usually means an API request lacked a valid token or key. The important point is that a 401 is about identity, not existence or permission level: the resource is there, and access is possible, but only after you authenticate correctly. If a 401 is unexpectedly locking users out of your site, our /services/website-rescue team can trace the failing authentication.
401 versus 403: the crucial distinction #
The difference between 401 and 403 confuses many people, yet it is simple. A 401 Unauthorized means you have not proven who you are, so the server asks you to authenticate; providing correct credentials should grant access. A 403 Forbidden means the server already knows who you are, or does not care, and is refusing regardless; logging in will not help because your identity is not permitted to view that resource. Put another way, 401 is you have not shown your ID, and 403 is your ID does not get you in here. This matters for building secure sites: use 401 when a resource simply needs a login, and 403 when a known user lacks the rights. Getting the code right shapes both user experience and how automated clients respond. Our /services/client-portals page builds membership and login systems where these distinctions are handled correctly so users see the right prompt at the right time.
Common reasons you see a 401 #
Several everyday situations produce a 401. The most frequent is an expired or invalid login session; after a period of inactivity, your authenticated session times out and the next request is treated as anonymous. A wrong username or password produces a 401 on submission. Password-protected pages and staging sites that use HTTP basic authentication return a 401 until you enter the correct details. For integrations, a missing, mistyped, or expired API key or token is the classic cause, and a token that has been revoked or has run past its expiry will fail the same way. Caching can complicate matters, occasionally serving a stale 401 after you have actually logged in, which a hard refresh clears. Because all of these come down to credentials, the fix is to supply correct, current authentication. Our /services/api-crm-integrations page focuses on managing keys and tokens so authenticated connections stay valid and refresh cleanly even under heavy, sustained use.
How authentication actually works #
Understanding the handshake behind a 401 makes it easier to fix. When you request a protected resource, the server checks for proof of identity in the request, typically a session cookie, an authorization header, or a token. If that proof is absent or invalid, the server responds with 401 and a WWW-Authenticate header stating which method it expects, such as Basic or Bearer. Your browser or client then supplies credentials and retries. For web logins, a valid session cookie usually carries your identity on each subsequent request until it expires. For APIs, a bearer token in the authorization header does the same job. If any part of that chain breaks, an expired token, a cleared cookie, a clock mismatch, the server falls back to 401. Knowing which mechanism a resource uses tells you exactly where to look. This is core to the secure login systems we build on our /services/website-security page.
Fixing a 401 in an API request #
For integrations, a 401 almost always means the authentication header is missing, malformed, or carrying an expired or revoked token. The quickest way to confirm this is to resend the request with a known-good token and compare the result, watching both the status code and the WWW-Authenticate header the server returns. Inspecting the request headers and the token's expiry timestamp usually pinpoints the exact problem in seconds, telling you whether to refresh the token, fix the header format, or request a new credential entirely.
# A request WITHOUT credentials returns 401:
curl -i https://api.example.com/v1/orders
# HTTP/1.1 401 Unauthorized
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# Retry WITH a valid bearer token in the Authorization header:
curl -i https://api.example.com/v1/orders \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
# HTTP/1.1 200 OK
# If it still fails, the token may be expired or revoked.
# Request a fresh token from the auth endpoint and retry.Troubleshooting a 401 on a web page #
When a visitor or you see a 401 on a normal web page, work through the identity chain. First, log out fully and log back in, which issues a fresh session and clears an expired one. Second, confirm the username and password are correct, watching for caps lock and autofill errors. Third, clear cookies and cache for the site, since a stale or corrupted session cookie can keep triggering the prompt. Fourth, if the page uses HTTP basic authentication, common on staging and protected areas, make sure you have the exact credentials, as these are separate from your normal account login. Fifth, check the device clock, because a badly wrong time can invalidate token-based sessions. If the whole site suddenly returns 401 for everyone, a server-side authentication setting or a misconfigured protection rule is likely the cause, not individual users. Our /services/managed-hosting team can inspect server-level authentication that affects all visitors at once.
Security implications of 401 responses #
A 401 is usually security working as intended, keeping unauthenticated visitors out of protected areas. But the pattern of 401s tells a story worth reading. A burst of 401s from many attempts on a login endpoint can indicate a brute-force attack probing for valid passwords, which is a cue to enable rate limiting, strong password rules, and multi-factor authentication. On the flip side, legitimate users hitting unexpected 401s may signal sessions expiring too aggressively or a token-refresh bug that frustrates customers. Well-designed authentication balances the two: strict enough to block attackers, smooth enough that real users stay logged in comfortably. Logging authentication failures, without recording the passwords themselves, helps you spot both problems. It is also good practice never to reveal in a 401 whether the username or the password was wrong, since that leaks information to attackers. Getting this balance right is central to the secure access systems on our /services/website-security page.
Best practices for designing 401 responses #
If you build login systems or APIs, a few practices make 401s helpful rather than frustrating. Always include the WWW-Authenticate header the specification requires, so clients know which authentication method to use. Return a 401 only when authentication genuinely would grant access, and reserve 403 for cases where a known user is simply not permitted, since mixing the two confuses both people and software. Keep error messages generic, never revealing whether the username or the password was wrong, because that detail helps attackers. Pair 401s with sensible rate limiting so repeated failures cannot fuel a brute-force attack. For token-based systems, implement smooth refresh so legitimate users are not logged out mid-task, and give clear, current expiry information. Log authentication failures without storing the credentials themselves, so you can spot attacks and bugs alike. Finally, make the path back to a valid session obvious, a clear login prompt or refresh flow. These habits are central to the secure, user-friendly access systems we build on our /services/client-portals page.
Preventing recurring 401 problems #
Most persistent 401 headaches come from session and token management, so that is where prevention pays off. Set session timeouts that are secure but not punishing, and implement smooth token refresh so authenticated users are not kicked out mid-task. For APIs, rotate keys on a schedule, store them securely rather than hard-coding them, and handle expiry by requesting a fresh token automatically instead of failing. Give users clear login prompts and helpful, non-revealing error messages so a genuine mistake is easy to correct. For protected staging sites, document the basic-authentication credentials so team members are not locked out. Monitor authentication logs for spikes that suggest attacks or bugs. When a 401 does appear, remember it is almost always about credentials: refresh the login, verify the details, and check token validity before looking anywhere else. If your logins, portals, or integrations keep throwing 401s, our /services/client-portals and /services/api-crm-integrations teams can build authentication that stays reliable.
FAQ
What does a 401 Unauthorized error mean in simple terms?
It means the server will not show you the page until you prove who you are with valid login details or credentials. You either sent none or sent the wrong ones. It is essentially the server saying please log in first. Providing correct, current credentials normally clears it right away.
What is the difference between a 401 and a 403 error?
A 401 means you have not authenticated, so logging in with valid credentials should grant access. A 403 means the server already recognizes you but is refusing anyway, so logging in will not help because your identity simply is not allowed to view that resource. In short, 401 is log in first, 403 is you still cannot enter.
Why do I keep getting a 401 error after logging in?
Usually your session cookie or token is expiring too quickly, is being blocked, or is stale in your browser cache. Try clearing cookies for the site, logging out fully and back in, and checking that your device clock is correct. If it persists for everyone, a server-side session setting likely needs adjusting.
How do I fix a 401 error in an API integration?
Check that your request includes a valid authorization header with a current token or key. A missing, mistyped, expired, or revoked token is the usual cause. Request a fresh token from the authentication endpoint, confirm it is placed in the correct header format, and retry. Reading the WWW-Authenticate header in the 401 response often names the exact problem.
Is a 401 error a sign of hacking?
A single 401 is normal and just means authentication is needed. However, many rapid 401s against a login endpoint can indicate a brute-force attack trying different passwords. If you see that pattern, enable rate limiting, enforce strong passwords, and add multi-factor authentication. Reviewing authentication logs helps you tell routine logins apart from an attack.
Can caching cause a false 401 error?
Yes. Occasionally a browser or proxy serves a stale 401 response even after you have logged in successfully. A hard refresh or clearing the site's cookies and cache usually resolves it. Properly configured sites avoid caching authenticated responses, so recurring cache-related 401s often point to a caching rule that needs correcting.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?