When should I return 4xx versus 5xx?
Return 4xx when the client can fix the request, credentials, or timing. Return 5xx when the request was reasonable but the server or an upstream dependency failed anyway.
Reference
Start here when you know whether the request succeeded, redirected, or failed, but you still need the code that matches what actually happened.
Interim responses that indicate request progress before a final response is sent. Protocol handshakes, continue flows, and early rendering hints.
Responses indicating the request was accepted and processed successfully. Successful reads/writes where the request was accepted and processed.
Responses that tell clients to perform additional actions, usually by following a new URL. URL changes and canonical migrations that preserve user navigation.
Client-side request issues such as invalid syntax, missing resources, or permission failures. Client-side request issues like missing resources, invalid auth, or rate limits.
Server-side failures where the request was valid but the server could not complete it. Server-side failures, upstream outages, and transient platform incidents.
No status codes match this filter.
Start from the symptom when you do not yet know the exact code.
Start with 404 diagnostics for deleted routes, stale links, and typos.
Use 401 when credentials are missing or invalid; pair with WWW-Authenticate.
Use 403 when identity is known but the action is not allowed.
Use 429 for throttling and communicate retry windows clearly.
Debug unknown origin failures and improve fallback behavior.
Signal maintenance or overload conditions with clear recovery hints.
Status codes are the shortest honest summary of what happened to a request. If your API returns the wrong one, clients retry the wrong thing, browsers behave differently, and debugging gets slower for everyone involved.
Most arguments about status codes happen when multiple answers sound plausible. This page helps narrow those cases down fast.
Return 4xx when the client can fix the request, credentials, or timing. Return 5xx when the request was reasonable but the server or an upstream dependency failed anyway.
Use 401 when the request lacks valid credentials and the client can authenticate again. Use 403 when the identity is known but still not allowed to do the thing it asked for.
Because some redirects preserve the original method and body while others switch the follow-up request to GET. The distinction affects forms, APIs, caches, and browser behavior.