How HTTP Works

Reference

HTTP Status Codes

Start here when you know whether the request succeeded, redirected, or failed, but you still need the code that matches what actually happened.

1xxInformational

Interim responses that indicate request progress before a final response is sent. Protocol handshakes, continue flows, and early rendering hints.

1xx class page

2xxSuccess

Responses indicating the request was accepted and processed successfully. Successful reads/writes where the request was accepted and processed.

2xx class page

3xxRedirection

Responses that tell clients to perform additional actions, usually by following a new URL. URL changes and canonical migrations that preserve user navigation.

3xx class page

4xxClient error

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.

4xx class page

5xxServer error

Server-side failures where the request was valid but the server could not complete it. Server-side failures, upstream outages, and transient platform incidents.

5xx class page

Error-First Navigation

Start from the symptom when you do not yet know the exact code.

How Status Codes Encode Outcome

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.

1xx informational
Interim responses that keep the exchange moving before the final answer is ready, such as 100 Continue or 103 Early Hints.
2xx success
The request worked. The details still matter, though: 200, 201, 202, and 204 all imply different follow-up expectations.
3xx redirection
The client is not done yet. It needs another URL, a different method, or cached state before the flow is complete.
4xx and 5xx errors
4xx means the request is wrong for the current client context. 5xx means the server or one of its dependencies failed to complete valid work.

Use This Hub When The Outcome Is Clear But The Code Is Not

Most arguments about status codes happen when multiple answers sound plausible. This page helps narrow those cases down fast.

  • Choose the code that matches the protocol outcome, not the wording of the exception in your app.
  • Look at related headers too: Location, Retry-After, WWW-Authenticate, and Cache-Control often finish the story.
  • Use class pages and the picker when the debate is between two valid-looking codes, not when you already know the answer.

Questions Teams Argue About

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.

When should I use 401 instead of 403?

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.

Why do redirects use different 3xx codes?

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.

Browse /search