HTTP Status Codes

HTTP Status Codes

A quick reference to every HTTP status code, explained with examples.

100

Continue

1xx
101

Switching Protocols

1xx
103

Early Hints

1xx
200

OK

2xx
201

Created

2xx
204

No Content

2xx
206

Partial Content

2xx
301

Moved Permanently

3xx
302

Found

3xx
304

Not Modified

3xx
307

Temporary Redirect

3xx
308

Permanent Redirect

3xx
400

Bad Request

4xx
401

Unauthorized

4xx
403

Forbidden

4xx
404

Not Found

4xx
405

Method Not Allowed

4xx
409

Conflict

4xx
413

Payload Too Large

4xx
422

Unprocessable Entity

4xx
429

Too Many Requests

4xx
500

Internal Server Error

5xx
502

Bad Gateway

5xx
503

Service Unavailable

5xx
504

Gateway Timeout

5xx

Features

  • Complete reference for all HTTP status codes (1xx–5xx)
  • Search by code number or descriptive keyword
  • Detailed description, common causes, and usage examples for each code
  • Color-coded by category: informational (1xx), success (2xx), redirect (3xx), client error (4xx), server error (5xx)
  • RFC reference links for each status code
  • Cacheable status codes highlighted

Common Use Cases

  • Look up the meaning of an unfamiliar HTTP status code in error logs
  • Choose the correct status code when designing an API response
  • Debug client or server errors reported by monitoring tools
  • Understand redirect chains and caching behavior
  • Learn HTTP semantics while building REST APIs

HTTP Status Codes

HTTP status codes are three-digit numbers returned by servers to indicate the result of a client request. They are grouped into five classes by their first digit:

  • 1xx Informational: request received, continuing process (100 Continue, 101 Switching Protocols)
  • 2xx Success: request was successfully received, understood, and accepted (200 OK, 201 Created, 204 No Content)
  • 3xx Redirection: further action needed (301 Moved Permanently, 302 Found, 304 Not Modified)
  • 4xx Client Errors: request contains bad syntax or cannot be fulfilled (400, 401, 403, 404, 429)
  • 5xx Server Errors: server failed to fulfill a valid request (500, 502, 503, 504)

Examples

Valid - 200 OK
200 OK — Standard response for successful HTTP request
Valid - 404 Not Found
404 Not Found — Resource could not be found on server
Invalid - 429 Too Many Requests
429 Too Many Requests — Rate limit exceeded by client

Frequently Asked Questions

What is the difference between 401 and 403?

401 Unauthorized: the client must authenticate (login) first. Despite the name, it means "unauthenticated." 403 Forbidden: the client is authenticated but does not have permission for this resource. Think of 401 as "who are you?" and 403 as "I know who you are, but you can't come in."

When should I use 301 vs 302 vs 307?

301 Moved Permanently: old URL is gone forever, browsers may cache this redirect. Use for SEO-friendly URL changes. 302 Found: temporary redirect; do not cache. 307 Temporary Redirect: like 302 but guarantees the HTTP method is preserved (POST stays POST). Use 307 when you need to temporarily redirect non-GET requests.

What is 204 and when should I use it?

204 No Content means the request succeeded but there is no response body. Use it for DELETE requests, or for PATCH/PUT when you don't return the updated resource. It tells the client "success, nothing more to say" without sending an empty JSON object.

What does 429 Too Many Requests mean?

The client has exceeded the API's rate limit. The server should include a Retry-After header indicating when the client may try again. Always implement rate limiting on public APIs to prevent abuse and ensure fair usage.

💡 Tips

  • Return <code>204 No Content</code> for successful DELETE operations — it's semantically cleaner than returning an empty JSON object.
  • Use <code>429 Too Many Requests</code> with a <code>Retry-After</code> header when rate limiting API clients so they know exactly when to retry.
  • Prefer <code>307 Temporary Redirect</code> over <code>302</code> for temporary redirects of POST endpoints to preserve the HTTP method.
  • Log 5xx errors with full request context — they always represent a bug in your system, not the client's fault.