HTTP Status Codes Cheat Sheet: Every Code Explained

Originally published on DevToolsHub — free, privacy-first online tools for developers.

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.

🔍 Quick Tip Use our

JSON Formatter

to prettify API error responses, and our

Base64 Encoder/Decoder

to decode token-based auth errors.

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 Permanently` redirect 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.

**** 🎯 Quick Summary

1xx — Informational: continue, switching protocols
2xx — Success: everything worked as expected
3xx — Redirection: resource moved, use different URL
4xx — Client Error: bad request, auth failure, not found (debug here first)
5xx — Server Error: server crashed, gateway timeout, overloaded
Use our JSON Formatter to read API error responses

Frequently Asked Questions

What is the difference between 401 Unauthorized and 403 Forbidden?

401 Unauthorized means the client is
not authenticated — no valid credentials
were provided, or the token is missing or expired.
403 Forbidden means the client
is authenticated but does not have
permission to access the resource. A logged-in user hitting an admin endpoint
should get 403; an anonymous request should get 401. Also note that the spec
recommends 401 include a
WWW-Authenticate header describing the auth scheme.

What is the difference between 301, 302, 307, and 308 redirects?

301 and 308 are
permanent redirects; 302 and
307 are temporary. The key difference is method
handling: 301 and 302
may rewrite POST into GET
(most browsers do), while 307 and
308 always preserve the method and request body.
Use 308 for permanent redirects of form
submissions or API endpoints, and 307 for
temporary ones where the method must survive.

When should I return 429 Too Many Requests?

Return 429 when a client exceeds your rate limit
— for example, more than 100 requests per minute. Always include a
Retry-After header (in seconds or an HTTP date)
so clients know when to try again, and consider adding
RateLimit-Limit,
RateLimit-Remaining, and
RateLimit-Reset headers for transparency. Use
503 instead when the whole service is overloaded
or down for maintenance, since that signals a server-side condition rather than a
client quota.

Should I return 404 or 403 for resources that exist but are not authorized?

For security-sensitive resources, returning 404
is usually the better choice. A 403 tells an
attacker that the resource exists, letting them enumerate your API. Returning
404 for both "not found" and "forbidden" hides
the resource's existence. Reserve 403 for cases
where revealing existence is fine, such as a public site telling a logged-in user
they lack admin rights.

What is the difference between 500, 502, 503, and 504?

500 Internal Server Error is a generic failure
inside your application — an unhandled exception or misconfiguration.
502 Bad Gateway means an upstream server (like a
reverse proxy's backend) returned an invalid response.
503 Service Unavailable means the server is
overloaded or in maintenance — pair it with
Retry-After.
504 Gateway Timeout means an upstream server
didn't respond in time. All four are server-side: check your application logs,
upstream health, and load balancer configuration in that order.

        **Related Tools:**
        [JSON Formatter](https://devtoolshub.cloud/tools/json-formatter)

        [Base64 Encoder/Decoder](https://devtoolshub.cloud/tools/base64)

        [JWT Decoder](https://devtoolshub.cloud/tools/jwt-decoder)