The HTTP 401 Unauthorized status code indicates that the request lacks valid authentication credentials for the target resource. This guide explains exactly when to use 401 (vs 403 Forbidden or 407 Proxy Authentication Required), the WWW-Authenticate header that must accompany it, common causes, fixes, and SEO…
HTTP 401 Unauthorized is the response code a server returns when the request lacks valid authentication credentials for the target resource. The name is somewhat misleading — 'Unauthorized' actually means 'unauthenticated' in HTTP terminology. The server is saying: 'I cannot identify who you are; provide valid credentials and try again.' Per RFC 9110 (the current HTTP specification), a 401 response must include a WWW-Authenticate header field specifying the authentication scheme(s) and parameters the server supports. Without this header, the response technically violates the HTTP specification, though most clients tolerate the omission.
Three HTTP status codes deal with authentication and authorization, and they're frequently confused. (1) 401 Unauthorized: 'I don't know who you are.' Use when no credentials were provided or credentials are invalid/expired. (2) 403 Forbidden: 'I know who you are, but you can't access this.' Use when the user is authenticated but lacks permission for this specific resource. (3) 407 Proxy Authentication Required: 'You need to authenticate with a proxy server first.' Use when authentication is required at the proxy layer, not the origin server. Misusing 403 in place of 401 is the most common mistake — if no Authorization header was sent or credentials are invalid, return 401, not 403. Our team's perspective on 401 response code comes from active client work, not theory.
(1) Missing Authorization header — the client never sent credentials. (2) Expired access token — OAuth tokens, JWTs, and session tokens have expiry timestamps; expired tokens trigger 401. (3) Invalid API key — wrong key, revoked key, or key for the wrong environment (dev key against prod, etc.). (4) Malformed Authorization header — incorrect prefix ('Token' instead of 'Bearer'), missing scheme, or invalid base64 encoding for Basic auth. (5) Session timeout — server-side session expired due to inactivity. (6) Wrong realm — credentials valid for one realm sent to another (common in Basic auth). (7) Clock skew — JWT validation can fail if client and server clocks differ significantly. If you're researching 401 response code, this page covers what actually moves the needle in 2026.
Per RFC 9110, every 401 response must include a WWW-Authenticate header indicating the authentication scheme(s) the server supports. Examples: WWW-Authenticate: Basic realm='Admin' (HTTP Basic auth), WWW-Authenticate: Bearer realm='api' (Bearer tokens for OAuth/JWT), WWW-Authenticate: Digest realm='secure' qop='auth' (HTTP Digest, rarely used today). For APIs using Bearer tokens, you may include error parameters: WWW-Authenticate: Bearer error='invalid_token', error_description='Token expired'. Browsers use the WWW-Authenticate header to render the appropriate authentication dialog. API clients use it to determine which credential type to send on retry.
If you're hitting a 401 in a browser: (1) Sign out and sign back in. (2) Clear cookies for the affected site. (3) Try an incognito/private window to rule out extension interference. (4) Check that your account has the required permissions. (5) Try a different browser to rule out browser-specific session corruption. If you're hitting 401 in an API client: (1) Verify your access token hasn't expired. (2) Confirm the Authorization header format matches the API's expected scheme. (3) Check whether your API key is active and assigned to the correct environment. (4) Verify the request URL matches the realm the credentials were issued for.
If your server is unexpectedly returning 401: (1) Check authentication middleware configuration — many frameworks require explicit setup. (2) Verify the WWW-Authenticate header is included in the response. (3) Check token validation logic — ensure issuer, audience, and signature validation work correctly. (4) Review session management — confirm session cookies are being sent and parsed correctly (CORS issues, SameSite settings, secure flag mismatches). (5) Inspect the actual request reaching your server — proxies, CDNs, and load balancers can strip Authorization headers. (6) For OAuth: verify token expiry handling and refresh token logic. (7) Log the specific reason for each 401 response in your application — this dramatically reduces debugging time. Our recent 401 response code engagements informed every recommendation on this page.
401 responses block search engine crawlers. If Googlebot encounters a 401 on a URL, it cannot access the content and the page will not be indexed. This is desirable for: admin areas, member-only content, internal tools, API endpoints, and any genuinely-private content. It's a serious bug for: public-facing pages mistakenly behind auth, content that should be indexed, marketing pages, blog posts, or product pages. If a public page is returning 401 to crawlers but not to logged-in users, it indicates an authentication bug or misconfigured middleware. Use Google Search Console's URL Inspection tool to check whether Googlebot can access your priority pages — any 401 (or 403) responses for public content require immediate investigation. Throughout our work on 401 response code, we cite primary sources and current data.
(1) Always include WWW-Authenticate per RFC 9110. (2) Return 401 (not 403) when no credentials are sent — this allows clients to know they should retry with auth. (3) Provide actionable error messages without leaking sensitive info ('Token expired' is fine; 'Token has invalid signature for user 12345' leaks internal details). (4) Use distinct error codes within 401 for different scenarios (invalid_token, expired_token, insufficient_scope) per OAuth 2.0 conventions. (5) Don't return 401 for genuine authorization failures — use 403 for those. (6) Don't return 200 with an error message body when you mean 401 — proper status codes are essential for client libraries to handle errors correctly. Considering 401 response code? Book a no-pressure strategy call to compare options.