A 401 Unauthorised error usually means the website does not recognise you. Your password may be wrong, your login may have expired, or an application may have forgotten to include the digital key it needs.
It does not normally mean you have been banned. In most cases, the website is simply asking you to prove who you are again.
This article is part of our Common Web Server Errors Explained series, which covers the error codes website owners are most likely to encounter.
The short version
If you see a 401 while browsing, sign in again and carefully re-enter your details. If you manage the website, first work out whether the login is controlled by the website, WordPress, the web server or another service.
Do not weaken or remove the login protection just to make the error disappear. Find out why the correct details are not being accepted.
What does a 401 Unauthorised error mean?
When a browser or application asks for something protected, the server checks for acceptable login details, known technically as credentials. If they are missing or invalid, the server returns a 401 response. It may also send a WWW-Authenticate header, which is a technical instruction describing the type of login it expects.
The resource may be a web page, an API endpoint, a file or an entire directory. The credentials might be a username and password, an API key, a bearer token, a browser session cookie or another form of identity.
The response is therefore quite specific: the server received the request, understood it and knows authentication is required, but it could not validate the request as submitted.
You may see a plain "401 Unauthorised" page, a browser login prompt, an application error or a custom message such as "Authentication required" or "Invalid credentials". The presentation changes, but the underlying meaning remains much the same.
401 vs 403: what is the difference?
A 401 and a 403 Forbidden error are easy to confuse because both stop access to a resource.
A 401 usually means the server does not recognise you as an authenticated user. Supplying valid credentials, refreshing an expired session or correcting the authentication method may resolve it.
A 403 means the server understood the request but refuses to grant access. You might be logged in correctly and still lack permission. A firewall, IP restriction, file permission or application role may be blocking you.
A useful way to think about it is that a 401 asks, "Who are you?", while a 403 says, "We know who you are, but you cannot access this."
If your error is actually a permission problem, see What Is a 403 Forbidden Error?.
Common causes of a 401 error
The most obvious cause is an incorrect username or password, particularly on a directory protected with HTTP Basic Authentication. Saved credentials can also become stale after a password change, causing the browser to keep submitting information that is no longer valid.
Expired sessions are another common cause. Websites typically use a cookie or token to remember that you have logged in. That session may expire after a period of inactivity, be invalidated after a security change or disappear when browser data is cleared. The next protected request then receives a 401.
API requests often fail because an authentication header is missing or malformed. A bearer token may have expired, an API key may have been revoked, or a reverse proxy may have removed the Authorization header before passing the request to the application. In these situations, the credentials may be correct but never reach the component that needs them.
Caching and security systems can contribute as well. A CDN or proxy should not normally cache a private 401 response for unrelated visitors, but incorrect cache rules can do exactly that. A security plugin may invalidate sessions after an IP address changes, while single sign-on systems can fail when clocks, callback URLs or signing certificates do not match.
Finally, the error may be deliberate. A development or staging site is often password-protected to keep it away from the public and search engines. In that case, the 401 is evidence that the protection is working.
How to diagnose a 401 error
Begin by identifying the scope. Does the error affect one person or everyone? Does it appear on one page, an entire website, an administration area or only an API request? Can you reproduce it in a private browser window or on another device?
If only one user is affected, the issue is more likely to involve saved credentials, browser cookies, an expired session or an individual account. Sign out completely, close the browser, clear the relevant site data and try again. Avoid clearing everything unless necessary; removing data for the affected domain is usually enough.
If every user is affected, review what changed. A password file may have been replaced, an authentication plugin may have updated, an identity provider may be unavailable or a deployment may have altered proxy configuration. A timestamp for when the issue began is often more useful than a screenshot alone.
For API failures, inspect the request and response rather than guessing. Confirm that the expected Authorization header leaves the client and reaches the application. Check the token issuer, audience, expiry time and required scopes. Be careful not to paste live passwords, tokens or API keys into tickets, logs or public debugging tools.
Server, proxy and application logs should show which component returned the 401. That distinction matters because a CDN-generated response has a different cause from one returned by NGINX, Apache, WordPress or a custom application.
How to fix a 401 error
If you are a visitor, first confirm the web address and credentials. Re-enter the username and password rather than relying on autofill, then try a private browser window. If the login works elsewhere, clear the stored data for that site in your usual browser.
If you manage the website, verify that the user account is active and has the expected role. Reset the password through the normal workflow rather than editing database values directly. For directory protection, check the .htpasswd file, the username configured in it and the web server rule pointing to the file.
For an application or API, generate a fresh credential and confirm the client is using the correct authentication scheme. An API expecting Bearer <token> will not accept a token sent in an unrelated header. Confirm that proxies and load balancers preserve authentication headers and that server clocks are synchronised when tokens rely on precise expiry times.
Review cache rules if a 401 persists after the underlying issue is fixed. Authentication pages and private responses should generally bypass full-page caching. Purge the relevant CDN, web server and browser caches after correcting the configuration.
Avoid weakening authentication merely to remove the error. Disabling a security control can make the page load again while creating a much larger problem. The aim is to restore valid access, not make protected content public.
401 errors in WordPress
WordPress normally displays its own login screen rather than a server-level 401, so a visible 401 often comes from something around WordPress.
A staging site may use HTTP authentication in addition to the WordPress login. Security plugins can restrict REST API access or invalidate sessions they consider suspicious. A CDN, web application firewall or host-level rule may protect /wp-admin, /wp-login.php or XML-RPC requests. Headless WordPress sites can also return 401 responses when the frontend calls a protected REST API endpoint without the correct cookie, nonce or token.
Start by determining whether the response is generated before WordPress loads. Server headers, log entries and the appearance of the error page can help. If a web server password prompt appears, changing WordPress credentials will not solve it. If the WordPress REST API returns a JSON authentication error, investigate the application, plugin and API credentials instead.
On a production site, test changes in staging where possible. Disabling every security feature on a live site may remove the symptom but also removes the protection you were relying on.
Is a 401 a hosting issue or an application issue?
It can be either.
Your hosting provider is responsible for server-level authentication, proxy behaviour and infrastructure configuration. They should be able to confirm where the response originated, review relevant logs and identify whether an authentication header is being lost between services.
The website owner or developer is usually responsible for application accounts, plugin settings, API credentials, custom login logic and role permissions. If the infrastructure passes the request correctly but the application rejects the token, the fix belongs in the application.
A useful hosting provider will help locate that boundary rather than simply repeat the error message. Diagnosis is often the most valuable first step.
How to prevent future 401 errors
Document where authentication is applied, particularly when a site has several layers. Keep ownership of service accounts and API keys with the business, rotate credentials deliberately and record expiry dates where applicable.
Monitor important integrations so an expired token is detected before a customer reports it. Test authentication after proxy, CDN, security and identity-provider changes. Keep recovery methods current, and ensure more than one authorised person can administer business-critical accounts.
For WordPress, maintain the core application and security plugins, but avoid automatic changes to authentication systems without testing. Exclude private and logged-in pages from inappropriate caching, and retain logs long enough to investigate intermittent failures.
Frequently asked questions
Does a 401 error mean my website has been hacked?
No. A 401 usually indicates missing or invalid authentication. Repeated 401 responses in logs may show bots attempting to access protected resources, but the code itself is not evidence of compromise.
Can clearing the browser cache fix a 401?
It can when stale cookies, sessions or saved credentials are involved. Clear data for the affected site and authenticate again. If every user sees the error, the cause is more likely on the server or application side.
Why does an API return 401 when the token looks correct?
The token may be expired, intended for a different service, missing a required scope or sent using the wrong scheme. A proxy may also be stripping the authentication header. Inspect the complete request path without exposing the secret itself.
Is a 401 bad for SEO?
Protected resources returning 401 responses are generally not intended to appear in search results. An accidental 401 on public pages can prevent search engines and visitors from accessing them, so it should be corrected promptly.
Should a missing page return 401?
Only if the server intentionally requires authentication before revealing whether the page exists. A public page that has been removed should normally return 404 Not Found, not 401.
Final thoughts
A 401 Unauthorised error is not a complete diagnosis. It tells you that authentication failed, but the failure may sit in the browser, web server, proxy, identity provider, WordPress plugin or application itself.
The fastest route to a lasting fix is to identify which layer returned the response, confirm what credentials it expected and work from the logs rather than trying random changes.
At Network Dynamics, our engineers can help diagnose the error, explain the cause in plain English and recommend a practical next step. You will not be left wondering whether the problem sits with the hosting platform, an account, WordPress, custom code or a third-party authentication service-or who needs to fix it.
Continue the series with What Is a 403 Forbidden Error? or return to Common Web Server Errors Explained.
