401 Unauthorized

The short version: A 401 Unauthorized means the server turned your request down because it lacks valid authentication: you have not proven who you are, or your login, token, or session is wrong or expired. The name is misleading, it really means "unauthenticated", not "forbidden". Clear it by re-entering the correct credentials, wiping cookies, or refreshing your API token.

Key takeaways

• 401 Unauthorized is about authentication, not permission. The server has no idea who you are yet, so it turned the request away and is asking you to prove your identity first.
• Do not confuse it with 403 Forbidden. A 401 fires when credentials are missing or invalid (identity); a 403 means the server knows you but says no (permission). Resending credentials does nothing for a 403.
• Every compliant 401 carries a WWW-Authenticate header (RFC 9110), and that header names the scheme the server wants back, Basic or Bearer for example. Read it first: it tells you exactly what to send.
• For a visitor, the cure is almost always to sign in again or wipe a stale session cookie. For a developer, look at a missing, expired, or wrong Authorization header, a bad token, or a misconfigured auth server.
• The host itself is fine when you get a 401, since the server is up and answering. A basic up-or-down ping will report it healthy even while a login or token-protected endpoint quietly turns everyone away.

Error type

HTTP 4xx client error

Whose side

Either: your credentials or the website's auth

Fix difficulty

Easy

Common cause

Missing, wrong, or expired credentials

What does 401 Unauthorized mean?

401 is an HTTP status code in the 4xx family, which puts the problem on the request side rather than a crash on the server. The resource is there, but access to it sits behind authentication, and the credentials you sent were missing, incomplete, or invalid. Alongside the 401 the server usually returns a WWW-Authenticate header naming the scheme it expects, Basic or Bearer for example. That header is the server saying: authenticate first, then try again.

Keep 401 and 403 Forbidden apart in your head. A 401 means you are not authenticated, so the server still has no idea who you are. A 403 means you are authenticated but barred from that specific resource. Who fixes a 401 depends on where you sit. As a visitor, it usually comes down to logging in again or correcting your details. As the website owner or someone calling an API, it points back to the credentials, the token, or the authentication configuration behind the request.

401

HTTP status code

4xx

Client-side error class

WWW-Authenticate

Header naming the expected scheme

How the 401 Unauthorized error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com/account

401

Unauthorized

This server could not verify that you are authorized to access this resource.

• 401 Unauthorized
• 401 Authorization Required
• HTTP Error 401
• HTTP 401
• Error 401
• Access Denied (401)

401 vs 400, 403 and 407

All four are 4xx client errors, but each points to a different reason the request was refused and a different person who can resolve it.

HTTP authentication schemes you will see in a 401

The WWW-Authenticate header on a 401 names one of these schemes, and each one expects a different value back in the Authorization header.

What causes 401 Unauthorized?

• You are not logged in, or the session timed out and its login cookie no longer counts as valid.
• The username and password sent with the request are wrong, mistyped, or simply absent.
• An API key or bearer token is invalid, revoked, or past its expiry, so the server rejects it.
• The Authorization header is missing, malformed, or uses the wrong scheme, sending Basic when the server expects Bearer, say.
• The page lives behind HTTP Basic Auth, like a staging website or a directory locked behind a username and password prompt.
• A WordPress area such as wp-admin, or a folder guarded by an .htaccess rule, is demanding credentials you have not supplied.
• A security plugin, firewall, or WAF flags the request as suspicious and blocks it before it ever reaches the application.

How to find the cause fast

1. Start by scoping it. Is it just you or everyone, one page or the whole website? A website-wide 401 points to a server, firewall, or .htaccess config; a single page usually means credentials or a protected area.
2. Open DevTools, reload, click the failing request, and read its response along with the WWW-Authenticate header to see which scheme the server is asking for.
3. Type your login again, slowly, then try an incognito window to rule out a stale or expired session cookie.
4. On an API, recheck the token value, its expiry, and its scope, and make sure the header goes out exactly as Authorization: Bearer YOUR_TOKEN.

Terminal

curl -sI https://example.com/accountHTTP/1.1 401 UnauthorizedWWW-Authenticate: Basic realm="Restricted"# the server wants valid credentials first

How 401 Unauthorized looks from the outside

A 401 slips past you if the homepage is all you watch: the public website keeps returning 200 while a protected API or login path drifts into 401. The only way to catch that from outside is to hit the authenticated endpoint itself, send a real token, and confirm the expected response, rather than treating a healthy front page as proof the login works. That gap between "the website is up" and "people can actually sign in" is exactly where auth breakages hide.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 401 Unauthorized

If you are a visitor

1. Log in again. A session from earlier may have expired, and a fresh login usually clears the 401 on its own.
2. Retype your username and password with care, watching for typos, stray spaces, and Caps Lock.
3. Clear that website's cookies and cache, then reload. A stale or corrupted login cookie is a frequent culprit.
4. Check the URL. An old link or a mistyped address can drop you on a protected resource you were never meant to hit directly.
5. Open a private or incognito window, or a different browser, to rule out a cached session or an extension getting in the way.
6. If the page is supposed to be public and keeps returning 401, contact the website owner. The configuration may be at fault rather than your access.

If you run the website or call the API

1. Send a valid Authorization header in the right format, for example Authorization: Bearer YOUR_TOKEN or Authorization: Basic BASE64_CREDENTIALS, and make sure it matches the scheme the WWW-Authenticate response named.
2. If the API key or token might be expired or revoked, regenerate or refresh it, then retry with the new value.
3. Look at the token's expiry and scopes. A token that is valid but missing the required scope, or past its lifetime, gets rejected all the same.
4. Go through the authentication configuration on the server: the auth middleware, the credentials it expects, and any environment variables or secrets used to validate requests.
5. For HTTP Basic Auth, confirm the realm plus the username and password the server expects. If a staging website is locked on purpose, supply the credentials or allowlist the caller.
6. Check security plugins, firewalls, or a WAF that might be intercepting authenticated requests, and add an exception when a legitimate request is being blocked.
7. Reproduce the request with curl or your API client, lining up a working call against the failing one to pin down the missing or malformed credential.

Still not fixed? Next steps

• Run curl -v on both requests, the one that works and the one that 401s, then diff the Authorization header byte for byte. A trailing space, a wrong scheme, or a token that got truncated is invisible in a browser.
• Own the API? Decode the rejected token at jwt.io or through your library and check its expiry (exp), audience (aud), issuer (iss), and scopes against what the endpoint actually demands before you blame the auth server.
• Watch for a CDN, reverse proxy, or load balancer quietly stripping the Authorization header before it reaches your origin. That is a classic source of a 401 that surfaces only in production.
• Credentials and config both check out but a public page still 401s? Take it to your host. A server-level auth rule, a forgotten staging password, or a WAF policy can enforce authentication you will never spot from the app.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Send a valid Authorization header (curl)

# Bearer token
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/v1/me

# HTTP Basic auth
curl -u username:password https://example.com/protected/

How to prevent 401 Unauthorized

Most 401s trace back to credentials or an auth endpoint that quietly stopped working. Pulsetic can monitor an authenticated URL on a schedule and run a keyword check to confirm the expected content loads, so when a protected page or login flow starts returning 401 you find out through email, SMS, Slack, or other alerts instead of through your users. It is an availability and uptime check, not a stand-in for auditing your auth logic, but it gives you an early warning when something breaks.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.