HTTP 401 Unauthorized: What It Means and How to Fix It

You load your site, or visit an API endpoint your app relies upon, and instead of a page you find a brief, unhelpful message: 401 Unauthorized. Sometimes a browser password box appears. Other times, a blank white page presents only that number. In either case, visitors are shut out, and if the error strikes your admin area, even you are left at the threshold.

The good news is that a 401 is one of the more honest HTTP responses. It tells you something specific. The server received your request, understood it, and decided you had not proven your identity. This problem is much narrower than a 500 error and is usually resolved in minutes once you know which layer is asking for credentials.

In this post we will explain what the 401 HTTP code means, describe the causes most often seen on WordPress and other CMS sites, and provide a step-by-step process for fixing it in your browser, server configuration, and REST API calls. We will also look at the case that matters most to us, when a sudden wave of 401s signals a deeper compromise rather than a simple configuration mistake.

Contents:

What is HTTP 401 Unauthorized?

HTTP 401 Unauthorized is a response status code that signals authentication has failed. The server received a valid request, but no acceptable credentials came with it. These may be missing, malformed, expired, or simply incorrect, so the server refuses to serve the resource.

It belongs to the 4xx family, which the HTTP specification calls client errors. That label deserves a second look, as it can be misleading. A 4xx code does not mean the visitor acted carelessly. Instead, it points to a problem in the request, not in the server’s ability to process it. Even a misconfigured rule on your server can produce 401s for well-behaved visitors throughout the day.

There is a second quirk in the naming. “Unauthorized” is really better called “unauthenticated.” A 401 means the server does not know who you are. If the server does know, but still denies access, it returns a 403 instead. We cover that code separately in our guide to HTTP error 403.

One technical detail is useful for diagnosis. A proper 401 response should include a WWW-Authenticate header that names the authentication scheme the server expects, such as Basic or Bearer. This header prompts a browser to display a username and password box when it encounters a 401. If you spot that header in the response, it reveals exactly which system is challenging you.

What does a 401 look like on a real site?

The wording depends on the server, the browser, and whatever is sitting in front of your site, so the same underlying problem shows up with different faces. Common variations include:

401 Unauthorized
HTTP Error 401 - Unauthorized
401 Authorization Required
Access denied due to invalid credentials
A native browser dialog asking for a username and password, which turns into a plain 401 page if you cancel or enter the wrong details

For API and application traffic you won’t see any of that. You’ll get a JSON or XML body with an error message, a 401 in your HTTP client’s logs, and a failed job somewhere downstream.

The practical consequence is the same in both cases. Human visitors hit a dead end and leave, which costs you trust and conversions. Search crawlers treat the URL as inaccessible, so if a 401 covers pages that are supposed to be public, those pages can drop out of the index while it persists. And if the affected URL is your own login or admin path, your ability to fix anything else on the site is blocked until the 401 is resolved.

What causes HTTP 401 errors?

In our experience the causes cluster into a handful of layers, and identifying the layer is most of the work. Some are mundane credential problems. Others are configuration, and a few are security events.

Wrong, expired, or revoked credentials: The simplest explanation, and still the most common. A password was changed, an API key was rotated, a bearer token expired, a service account was disabled.
A broken or stale login session: Authentication cookies that no longer match what the server expects, whether from a domain change, a switch between www and non-www, an HTTP-to-HTTPS migration, or a plugin that regenerates session keys, can make an authenticated user look anonymous. If you’ve recently moved protocols, our walkthrough on moving WordPress from HTTP to HTTPS covers the cookie and URL details that tend to get missed.
HTTP authentication at the server level: Directory password protection, commonly implemented with .htaccess and an .htpasswd file on Apache or equivalent directives on Nginx, returns 401 by design. It breaks in predictable ways. The password file path may no longer exist, the hash format may be unreadable, file permissions might block access, or protection could remain on a staging directory after it goes live.
Plugin and theme conflicts: Security, membership, caching, and SSO plugins all touch authentication. Two of them handling login or REST authorization at once can produce 401s that appear only for certain roles or certain endpoints.
Something in front of your site: A reverse proxy, CDN, firewall, or load balancer can strip the Authorization header, cache an authenticated response, or apply an access rule you’ve forgotten about. Protected paths combined with aggressive caching are a classic source of intermittent, difficult-to-reproduce 401s.
API authentication mismatches: Sending credentials the endpoint doesn’t accept — basic auth where a bearer token is required, a missing nonce on a cookie-authenticated request, a token scoped to the wrong user or site.
Malware or an unauthorized change to authentication: This is the one site owners tend not to consider. Code injected into a theme, a plugin, or a must-use plugin directory can hook authentication functions, replace the login handler, or add its own access check. The result can be legitimate users and admins suddenly receiving 401s. We will return to this point below.

How to fix a 401 error, step by step

Work from the cheapest check to the most invasive. Stop as soon as the error clears.

Reload the URL and confirm the exact code. Open your browser’s developer tools, go to the Network tab, and look at the failing request. Confirm it’s really 401 and not 403 or 419. Note the response headers, especially WWW-Authenticate.
Try the URL in a private window and a second browser. If it works there, the problem is local state — a stale cookie or cached credential — not the server.
Clear cookies and site data for the domain. Then log in again. For WordPress, clear cookies for both the bare domain and the www variant if both are in use.
Check whether the whole site or one path is affected. A 401 on /wp-admin/ only, or on one API route only, narrows the search dramatically compared to a site-wide 401.
Reset the credential involved. Change the user password, regenerate the API key or application password, re-issue the token. If a service integration broke, this fixes a surprising share of cases.
Inspect your .htaccess and server auth config. Look for AuthType, AuthUserFile, and Require directives (or Nginx auth_basic blocks). Confirm the password file path is correct and readable. Temporarily comment out the block, reload, and see whether the 401 disappears. If it does, you have confirmed server-level auth as the culprit. Keep a backup of the file before editing.
Flush every cache you have. Plugin cache, server cache, object cache, CDN, and your own browser. Then test again. Authenticated responses that got cached and served to everyone are a common cause of 401s that come and go.
Bypass or pause the layer in front of your site. If you use a CDN, proxy, or firewall, test the origin directly where your hosting setup allows it. If the 401 only appears through the proxy, the rule or header handling lives there.
Deactivate plugins methodically. Deactivate all of them, confirm the error is gone, then reactivate one at a time until it returns. On a site you can’t log into, rename the plugins directory over SFTP or in your host’s file manager to force a bulk deactivation, then rename it back and work through plugins individually. Switching temporarily to a default theme rules out theme-level interference.
Review server and firewall logs. Your error log and access log show which component issued the 401 and for which path. This is often the step that turns guesswork into a clear answer. Try it sooner if the first steps do not resolve the problem.
Ask your host. Hosts apply password protection to staging environments, rate-limit or challenge admin paths, and occasionally block requests at the edge. Support can see rules you can’t.

How do I fix 401 errors in REST API calls?

API 401s are rarely mysterious once you look at the actual request rather than the client library’s error message. Log the full outbound request — minus secrets — and check these in order.

Is the `Authorization` header actually arriving?

Some proxies and server configurations drop it. On Apache with CGI/FastCGI setups, the header may need to be passed through explicitly. Hit the endpoint with curl from the same network to compare.

Is it the right scheme?

Authorization: Bearer <token> and Authorization: Basic <base64> are not interchangeable. The WWW-Authenticate header on the 401 response tells you which one the endpoint wants.

Has the token expired or been revoked?

Short-lived tokens need a refresh path. If your integration worked for a while and then stopped at a regular interval, assume expiry first.

For the WordPress REST API specifically: cookie-based authentication also requires a valid nonce sent with the request, so a logged-in session alone isn’t enough for write operations from external contexts. Application passwords are the usual choice for server-to-server calls, and they must belong to a user whose role actually has the capability for that endpoint — a token with the wrong user attached produces a 401 or a permissions error that reads like one. Also confirm you’re calling the right base path, since a rewrite or a plugin can change where REST routes live.

Is a security layer challenging you?

Automated requests to admin or API paths can trip firewall rules. Allowlisting the IP or the specific route for your integration fixes it, and this is better than loosening the rule globally. If your API client is hammering an endpoint, check for rate limiting as well. That usually appears as HTTP 429 instead of 401, which makes it easier to tell the two situations apart.

When is a 401 a sign of a security problem?

Most 401s are configuration. A few are not, and the pattern is what gives them away.

Treat a 401 as a possible security event when it appears suddenly without a corresponding change on your side, when legitimate administrators are locked out while the front end works normally, when a password box appears on a path you never protected, or when 401s spike across many URLs at once. Another signal we take seriously is when your own credentials stop working and a password reset does not restore access.

Why would an attacker cause 401s at all? Usually not deliberately. Injected code that hooks authentication, redefines the login handler, or adds an access check can break authentication as a side effect of maintaining its own backdoor. In other cases the 401s are collateral damage from a cleanup that removed part of a malicious plugin but left its hooks in place. And if someone has added their own password protection to a directory, that’s an attempt to keep others out of a foothold they’ve established.

If 401 errors spike across your site after a suspected incident, do not just clear the error. Find out what changed. Scan the site for malware, compare core, plugin, and theme files against known-good copies, and look specifically at the files that run on every request. Check items like the theme’s functions.php, the must-use plugins directory, wp-config.php, and recently modified files anywhere under your web root. Then audit accounts. Review the user list for administrators you do not recognize, check the last-modified times on user records if your setup logs them, rotate every password and API key, and revoke application passwords and sessions.

One caveat worth stating plainly: a 401 on its own is not evidence of a hack. It is a prompt to investigate. The combination of unexplained authentication failures and unexpected file changes is what should move you from troubleshooting to incident response.

How to prevent future 401 errors

A few habits remove most of the recurring causes.

Document every place authentication is enforced – Server-level password protection, plugin-level restrictions, firewall rules, proxy rules, and host-applied staging protection. When a 401 appears, the list tells you where to look instead of starting from zero.
Remove protection you no longer need – Staging password protection that follows a site into production is one of the most common self-inflicted 401s we hear about. Make “remove directory auth” part of your go-live checklist.
Manage credentials deliberately – Use a password manager, give each integration its own key or application password scoped to the least-privileged user that can do the job, and record expiry dates for tokens so renewals are planned rather than discovered.
Keep authenticated responses out of shared caches – Make sure protected paths are excluded from page and CDN caching, and that Vary and cache-control behavior on those routes is correct.
Test auth changes on staging – Any change to .htaccess, server config, SSO, or a membership plugin should be exercised against a real login and a real API call before it reaches production.
Monitor rather than wait for reports – Uptime and status-code monitoring on your login path and your critical API endpoints catches a 401 before a customer does. File integrity monitoring catches the unauthorized change that causes the bad kind of 401.
Harden the surrounding configuration – Enforce HTTPS, use strong security headers, and keep core, plugins, and themes updated. Much of the authentication breakage traces back to half-finished migrations and abandoned extensions. Our guides on HSTS and HTTP security headers cover the response headers worth setting while you are there.

Wrapping up

A 401 is a narrow, legible message. Something asked for credentials and did not get acceptable ones. Find out which layer did the asking, whether it was a browser session, server directive, plugin, proxy, or API endpoint, and the fix usually follows in a step or two. Check credentials and cookies first, then server auth config, then caches and the layers in front of your site, then plugins, and read your logs before you start changing things.

The part that’s easy to skip is the question behind the error. If authentication broke and nobody changed anything, treat that as worth investigating rather than clearing. Scanning for malware, verifying file integrity, and reviewing your administrator accounts turns a one-off fix into something closer to assurance that the 401 wasn’t a symptom of a larger problem.

If you are troubleshooting other status codes as well, our explanations of 500 internal server errors and 502 bad gateway cover the server-side failures that often appear in the same week as a configuration change.

Frequently asked questions

What does a 401 error mean?

It means authentication failed. The server received and understood your request but found no acceptable credentials attached. They may be missing, expired, or incorrect, so the server refused to return the resource. Despite the word “Unauthorized,” a 401 really means unauthenticated. The server does not yet know who you are.

What’s the difference between 401 and 403?

A 401 means the server could not authenticate you and will accept another attempt with valid credentials, which is why it often triggers a login prompt. A 403 means authentication is not the issue. The server knows who you are, or does not care, and is refusing access to that resource outright. Supplying credentials will not help.

Why do I see a 401 on my login page after a hack?

Injected code can hook authentication functions, replace the login handler, or add password protection to admin paths, locking out legitimate users while a backdoor keeps working. Scan for malware, compare core and plugin files against known-good copies, check must-use plugins, then rotate passwords, API keys, and sessions.

How do I fix 401 errors in REST API calls?

Log the actual outbound request. Confirm the Authorization header reaches the server and isn’t stripped by a proxy, that the scheme matches what the WWW-Authenticate header asks for, and that the token hasn’t expired. For the WordPress REST API, cookie authentication also needs a valid nonce, and application passwords need a user with the right capability.

Is HTTP 401 a client error or a server problem?

Technically it is a 4xx client error, meaning the issue is in the request rather than in the server’s ability to process it. In practice, the root cause is often on the server side. A misconfigured .htaccess rule, a stale password file, a proxy dropping headers, or a plugin conflict can all be responsible. Be sure to investigate both sides.

Can 401 errors hurt my search rankings?

A 401 tells crawlers the URL is inaccessible, so pages meant to be public can lose visibility while the error persists. Intentional 401s on admin, staging, or API paths are fine and expected. The risk comes from accidental protection on public URLs, which is worth catching with status-code monitoring.