Skip to content
WebAuditOS
Start free audit

Test your website now

Free, no card. We read only public pages.

Run free audit →

HTTP errors

What does 401 Unauthorized mean, and how do you fix it?

A 401 means the request lacks valid credentials. How it differs from 403, why APIs return it, and how to fix missing or expired tokens in your own app.

401 Unauthorized means the server needs valid authentication and the request did not provide it, or provided credentials that are missing, wrong or expired. Signing in or sending a valid token can fix it. With an API, check that the key or token is present, sent in the right header and not expired.

Published · Last updated

By Michal Měřínský. Audit methodology.

What 401 Unauthorized means

Despite its name, 401 is about authentication, not permission. The server is saying: I do not know who you are, prove it. The specification requires a 401 response to include a WWW-Authenticate header describing how to authenticate, such as Basic or Bearer.

The difference from 403 matters when you debug:

  • 401 - no valid credentials. Logging in or sending a correct token can fix it.
  • 403 - credentials may be fine, and the answer is still no. Retrying with the same identity will not help.

If you are a visitor

A 401 means the page needs a login. If a browser pop-up asks for a username and password, the site uses basic authentication, often on staging or private areas. If you expected access, sign in again: your session may have expired.

Why your app or API returns 401, most likely first

  • The token or API key is missing from the request, often because an environment variable is empty in production.
  • The token is sent in the wrong place or format. Many APIs expect Authorization: Bearer followed by the token, and reject a key placed in the body or a custom header.
  • The token has expired. Short-lived access tokens, such as JWTs, need refreshing.
  • The key belongs to a different environment, project or account than the endpoint.
  • A session cookie is not being sent, because of SameSite rules, a different domain or a missing credentials setting on a cross-origin request.
  • Basic authentication protects a staging or preview deployment.

How to fix it

Reproduce the request outside your app so you can see exactly what is sent:

curl -i https://api.example.com/v1/me \
  -H "Authorization: Bearer $API_TOKEN"
  • If curl works and your app does not, the app is not sending the header. Log the outgoing request headers, with the token value masked.
  • If curl fails too, check the key in the provider's dashboard: is it active, and does it belong to this project?
  • For expired tokens, implement refresh, or re-authenticate when a 401 comes back.
  • For cross-origin requests that rely on cookies, the request must include credentials and the server must allow them for your exact origin.

Never log full tokens or API keys while debugging, and never paste them into client-side code to make a 401 go away. A key in the browser is a key anyone can copy.

When a 401 is the right answer

Protected API routes, account pages and staging environments should answer 401 to anonymous requests. That is the system working. The questions to ask are whether protected areas are linked from public pages unnecessarily, and whether login forms are only ever served over HTTPS.

Google treats 401 like other 4xx responses: the page is not available, and an indexed URL that starts returning 401 is removed. That is correct for private pages. It is a problem when a preview password is accidentally left on production. Google also notes that 401 does not reduce its crawl rate.

What a scan can and cannot tell you

WebAuditOS deliberately does not grade 401 responses as errors, because a login wall answering a crawler is usually intentional. It does check whether admin interfaces are linked from public pages and whether password fields appear on pages served without HTTPS.

A public scan cannot test what happens after login, whether tokens expire correctly, or whether your API checks authentication on every route.

A page that should be public but returns 401 will not be flagged as an error. If public pages disappear from search, check whether staging protection reached production.

Short answers

Is 401 the same as 403? No. 401 means not authenticated, 403 means authenticated or not, the answer is no.

Why does my API key work locally but return 401 in production? The production environment variable is missing, misspelled or holds a key from another project.

Can a CORS problem look like a 401? Yes, when cookies are not sent on cross-origin requests.

Should a login page return 401? No. The login page itself should load with 200. Protected resources return 401.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.

HTTP errors

What does 403 Forbidden mean, and how do you fix it?

A 403 means the server understood the request and refused it. The usual causes, how to fix each on your own site, and when a 403 is the right answer.

Security

What is a JWT, and how does JWT authentication work?

A JWT is a signed token carrying claims about a user. How it works, how to verify one, where to store it, and common mistakes.