HTTP Status Codes Cheat Sheet

Every web developer encounters HTTP status codes daily. From successful 200 OK responses to mysterious 418 I'm a Teapot — understanding what each code means is essential for debugging APIs, configuring servers, and building robust applications.

This cheat sheet covers every standard HTTP status code from 100 to 511, grouped by category. Use it as a quick reference whenever you encounter an unfamiliar response code.

1xx Informational Responses

These codes indicate that the server has received the request headers and the client should continue sending the request body. They are provisional responses — the client should wait for a final response.

2xx Success Responses

The request was successfully received, understood, and accepted. These are the codes every developer loves to see.

3xx Redirection Responses

The client must take additional action to complete the request. Usually means the resource has moved or the request needs different treatment.

4xx Client Error Responses

The request contains bad syntax or cannot be fulfilled. These are the most common errors you'll encounter while debugging APIs.

5xx Server Error Responses

The server failed to fulfill a valid request. These indicate problems on the server side — but sometimes the real issue is upstream.

Quick Reference by Category

Some status codes appear in unexpected places. Here's a breakdown of which codes are commonly seen in specific scenarios:

Common Mistakes & Best Practices

1. Don't Use 200 for Everything

Many poorly designed APIs return 200 OK for everything, including errors, and handle them in the response body. This breaks HTTP semantics and makes debugging harder. Use the correct status code for each scenario.

2. 401 vs 403 — Know the Difference

401 Unauthorized means the client is not authenticated (no valid credentials). 403 Forbidden means the client is authenticated but lacks permission. Use them correctly — a logged-in user hitting an admin endpoint should get 403, not 401.

3. Always Return Proper Error Bodies

When returning 4xx or 5xx, include a structured error response body:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email is required",
    "details": [
      { "field": "email", "issue": "must not be empty" }
    ]
  }
}

4. Use Retry-After With 429 and 503

When rate-limiting (429) or serving maintenance pages (503), include the Retry-After header so clients know when to retry. This prevents thundering herd problems.

5. 301 Redirects Are Cached by Browsers

A 301 Moved Permanentlyredirect is aggressively cached by browsers. If you accidentally serve a 301 to the wrong URL, clients will cache it and you'll have trouble fixing it. Use 302 or 307 for temporary redirects.