What Is HTTP 401 Unauthorized?

HTTP 401 Unauthorized means the server received the request but will not respond until the client proves who it is. The resource exists, the server is working fine, but access requires valid credentials that have not been provided — or the credentials that were provided are not valid.

Despite its name, 401 is really about authentication, not authorization. The naming is a historical inconsistency in the HTTP specification that has caused confusion ever since.

Authentication vs authorization

The distinction matters for understanding what 401 actually means.

Authentication is the process of proving who you are. Authorization is the process of determining what you are allowed to do. A 401 means authentication has failed or has not been attempted. A 403 means authentication may have succeeded, but you are not allowed to access this resource regardless.

In plain terms: a 401 says "I do not know who you are." A 403 says "I know who you are, and you cannot come in."

What causes a 401 error?

• No credentials provided. A request was made to a protected resource without any authentication information. The server responds with a 401 and typically includes a WWW-Authenticate header telling the client what type of credentials are expected.

• Invalid credentials. A username and password were provided but are incorrect. A token was sent but has expired or does not match any valid session.

• An expired session. The user was previously authenticated but the session has since timed out. Further requests return 401 until the user logs in again.

• A misconfigured server or application. Authentication middleware is applied to a route that should be public, or credentials are not being passed correctly between services.

What visitors see

A visitor hitting a 401 on a website typically sees a login prompt — either a browser-native HTTP authentication dialog or a redirect to a login page, depending on how the site handles authentication. If neither is configured, they see a generic error page.

In either case, the visitor cannot access the content without providing valid credentials.

401 vs 403 — what is the difference?

This is the question that comes up most often with these two codes, and the answer is straightforward once the authentication vs authorization distinction is clear.

A 401 means the server does not know who is making the request. Providing correct credentials could grant access. A 403 means the server knows who is making the request — or has decided it does not matter — and the answer is no regardless.

A practical example: trying to access an admin panel without being logged in returns a 401. Logging in as a regular user and then trying to access the same admin panel returns a 403.

Some servers and applications blur this distinction in practice. A 403 is sometimes returned instead of a 401 deliberately, to avoid revealing that a protected resource exists at all. This is a security measure, not an error.

How serious is a 401 in scan results?

A 401 on an internal URL means your crawler encountered a page on your own website that requires authentication. This is often expected — member areas, dashboards, and admin panels are legitimately protected. If dislike404.com is scanning a URL that is behind a login, a 401 is the correct response and not a problem.

It becomes worth investigating if a 401 appears on a URL that should be publicly accessible — a blog post, a product page, a landing page. In that case, something in your authentication configuration is incorrectly protecting a public resource.

A 401 on an external URL is generally not actionable. The linked page requires credentials that you do not have, or the resource has been moved behind a login since you linked to it. If the link is meant to point visitors to publicly accessible content, it is worth replacing with a working URL.

How to fix a 401 on your own website

• If the 401 is on a page that should be public, check your authentication middleware or route configuration. A route guard, a .htaccess rule, or an authentication plugin may be incorrectly applied.

• If the 401 is expected — the page is genuinely protected — no fix is needed. Consider adding the URL to your blacklist in dislike404.com to suppress it from future scan results.

• If the 401 is appearing because credentials are not being passed correctly between services or API clients, check that the Authorization header is included and formatted correctly in outgoing requests.

Finding 401 errors in your scan results

dislike404.com reports 401 responses in your scan results alongside other error codes. For most websites, a handful of 401s on known protected URLs is normal. If 401 errors appear on URLs that should be public, that is the signal worth acting on.