HTTP 401 Unauthorized

HTTP 401 Unauthorized indicates the request was not fulfilled due to a client-side issue (inputs, credentials, permissions, or request shape). It usually requires changing the request or client behavior rather than retrying blindly.

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

curl -i "https://httpstatus.com/api/status/401"
Try in playground

Meaning

Authentication is required and has failed or has not yet been provided. Response must include WWW-Authenticate header.

What it guarantees
  • The request was not fulfilled due to a client-side issue.
  • Authentication is required or did not succeed.
What it does NOT guarantee
  • Retries will succeed without changing request inputs.
  • The server is healthy; it may still be failing for other reasons.

When to use this status

  • Missing credentials or invalid/expired credentials.
  • APIs that require a challenge via WWW-Authenticate.
  • Browser flows where sign-in is required before access.

When NOT to use this status (common misuses)

Using 400 for authentication/authorization failures.
Clients cannot distinguish validation vs auth; retry/login flows break.
Using 404 to mask permission issues everywhere.
Monitoring misclassifies access bugs; SEO can degrade if real pages appear missing.
Returning 4xx for server-side bugs.
Clients stop retrying; incidents are masked as client behavior.
Returning 401 without WWW-Authenticate when required.
Clients cannot determine how to authenticate; browser/API flows break.

Critical headers that matter

Content-Type
Defines error body format (JSON/text/problem+json).
Clients can’t parse structured errors; observability loses fidelity.
Cache-Control
Prevents caching transient errors unless intended.
CDNs cache failures; prolonged user-visible outages.
WWW-Authenticate
Communicates auth scheme and challenge.
Clients cannot negotiate auth; automated refresh flows fail.

Tool interpretation

Browsers
Displays an error state; devtools exposes status and headers. Cache headers can accidentally cache error documents.
API clients
Classifies as failure; retry policy depends on idempotency and code class. Structured errors improve handling.
Crawlers / SEO tools
Persistent failures reduce crawl rate; soft-404 patterns cause indexing instability.
Uptime monitors
Typically alerts based on rate/threshold. Consistent classification reduces false positives.
CDNs / reverse proxies
May cache errors if misconfigured; respects Cache-Control and can serve stale on origin failure.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
  • Error cacheability and retry guidance signals
Correctness warnings
  • Missing WWW-Authenticate breaks standard auth negotiation.

Guided Lab outcome

  • Reproduce HTTP 401 Unauthorized using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
  • Identify the minimum request changes required to move from client error to success.

FAQ

Should clients retry on HTTP 401?
Usually no—fix the request. Exceptions exist when credentials can be refreshed.
Is HTTP 401 cacheable?
Generally should not be cached unless explicitly intended; use Cache-Control to prevent sticky failures.
Which headers matter most for HTTP 401?
Content-Type and Cache-Control are the baseline. Some codes also require Location, WWW-Authenticate, or Retry-After.
How does this affect monitoring?
Client errors should be tracked as contract/UX issues; page only if widespread.
How does this affect crawlers/SEO?
SEO impact is driven mostly by cacheability, canonical stability, and content correctness.
What should error responses include?
A stable, machine-parseable format with correlation IDs and actionable messages.

Client expectation contract

Client can assume
  • The request failed due to client-side inputs or policy.
Client must NOT assume
  • Retries without changes will succeed.
Retry behavior
Do not retry until the request is corrected (or credentials refreshed).
Monitoring classification
Client error
Use payload and header checks to avoid false positives; cacheability depends on Cache-Control/ETag/Vary.

Related status codes

400 Bad Request
The server cannot or will not process the request due to an apparent client error.
403 Forbidden
The request was valid, but the server is refusing action.