When should I use 200 vs 201 vs 204?

Use 200 OK for successful GET, PUT, or PATCH requests that return data. Use 201 Created for successful POST requests that create a new resource (include a Location header pointing to the new resource). Use 204 No Content for successful DELETE requests or updates that do not return a response body. These distinctions help API consumers handle responses correctly.

What does a 429 Too Many Requests status mean?

A 429 status code indicates the client has sent too many requests in a given time period and is being rate-limited. The server should include a Retry-After header indicating how long the client should wait before making another request. Common causes include API rate limits, DDoS protection, and brute force prevention. Implement exponential backoff in your client code when you receive 429 responses.

What is the difference between 301 and 302 redirects?

301 Moved Permanently tells browsers and search engines that the resource has permanently moved to a new URL. Search engines transfer SEO value to the new URL. 302 Found (temporary redirect) indicates the resource is temporarily at a different URL and the original URL should continue to be used. Use 301 for domain migrations and permanent URL changes. Use 302 for temporary maintenance pages or A/B testing.

How do I debug 500 Internal Server Error?

A 500 error means something went wrong on the server, but the response typically does not reveal the specific problem for security reasons. To debug: check your server logs (the actual error with stack trace will be there), look for recent code deployments that might have introduced bugs, verify database connectivity, check for null pointer exceptions or unhandled edge cases, and test with the same request parameters in a development environment where detailed errors are enabled.

HTTP Status Codes Guide: Every Code Explained

By Shannon Patterson · March 29, 2026 · 9 min read

Every HTTP response begins with a three-digit status code that tells the client exactly what happened with their request. Whether you are building REST APIs, debugging a failed webhook, or wondering why your browser shows a blank page, understanding HTTP status codes is fundamental to web development. Yet many developers only know a handful - 200, 404, and 500 - and miss the nuances that make APIs predictable and debuggable.

This guide covers every status code category with practical examples and debugging advice. Bookmark our HTTP Status Codes reference tool for quick lookups when you are in the middle of debugging.

1xx: Informational Responses

1xx codes indicate that the server has received the request and is continuing to process it. You rarely see these in typical web development, but they matter for advanced use cases.

100 Continue: The server has received the request headers and the client should proceed to send the request body. Used when clients send an Expect: 100-continue header before uploading large payloads, allowing the server to reject the request before the body is transmitted.
101 Switching Protocols: The server is switching to a different protocol as requested by the client. The most common use case is upgrading an HTTP connection to a WebSocket connection.
103 Early Hints: Allows the server to send preliminary headers (like Link headers for preloading resources) before the final response. This helps browsers start fetching CSS and JavaScript earlier.

2xx: Success Codes

2xx codes indicate the request was successfully received, understood, and accepted. Choosing the right 2xx code for your API responses makes them more predictable for consumers.

200 OK: The standard success response. Use for GET requests returning data, PUT/PATCH requests returning the updated resource, and any other successful operation that returns a body.
201 Created: A new resource was successfully created. Use for POST requests that create entities. Include a Location header with the URL of the new resource.
204 No Content: The request succeeded but there is no body to return. Perfect for DELETE operations and updates where the client does not need the response body.
206 Partial Content: The server is returning only part of the resource, as requested via a Range header. Used for resumable downloads and video streaming.

3xx: Redirection Codes

3xx codes tell the client that further action is needed to complete the request, usually following a redirect to a different URL.

301 Moved Permanently: The resource has permanently moved. Browsers cache this redirect and search engines transfer link equity to the new URL. Use for domain changes and permanent URL restructuring.
302 Found: Temporary redirect. The resource is temporarily at a different URL. Browsers do not cache this redirect. Use for maintenance pages or temporary routing.
304 Not Modified: The resource has not changed since the client last requested it (based on If-None-Match or If-Modified-Since headers). The client should use its cached version. Critical for performance.
307 Temporary Redirect: Like 302, but guarantees the request method and body will not change. If you POST to a URL that returns 307, the browser will POST to the new URL (not downgrade to GET).
308 Permanent Redirect: Like 301, but preserves the request method. The permanent version of 307.

4xx: Client Error Codes

4xx codes indicate the client sent a bad request. These are the most important codes for API design because they guide developers to fix their requests.

400 Bad Request: The server cannot process the request due to malformed syntax, invalid parameters, or missing required fields. Include a descriptive error message in the response body explaining what is wrong.
401 Unauthorized: The client has not provided valid authentication credentials. Despite the name, this is about authentication (identity), not authorization (permission). Return a WWW-Authenticate header indicating the expected auth scheme.
403 Forbidden: The client is authenticated but does not have permission to access the resource. The server knows who you are but will not let you in.
404 Not Found: The requested resource does not exist. Can also be used intentionally to hide the existence of resources from unauthorized users (instead of returning 403).
405 Method Not Allowed: The HTTP method is not supported for this URL. For example, trying to DELETE a read-only resource. Include an Allow header listing valid methods.
409 Conflict: The request conflicts with the current state of the server. Common for duplicate creation attempts, optimistic concurrency conflicts, or conflicting updates.
422 Unprocessable Entity: The request is well-formed but semantically invalid. For example, a JSON body that parses correctly but contains a negative value for an age field. Increasingly popular as a more specific alternative to 400.
429 Too Many Requests: Rate limit exceeded. Include a Retry-After header indicating how long the client should wait.

5xx: Server Error Codes

5xx codes indicate something went wrong on the server side. These should always be logged and investigated.

500 Internal Server Error: A generic catch-all for unexpected server errors. Never expose stack traces or internal details in production responses. Log the full error server-side for debugging.
502 Bad Gateway: A reverse proxy or load balancer received an invalid response from the upstream server. Usually means the backend service is down or returning garbage.
503 Service Unavailable: The server is temporarily unable to handle requests, typically due to maintenance or overload. Include a Retry-After header when possible.
504 Gateway Timeout: The reverse proxy or gateway did not receive a response from the upstream server within the allowed time. Usually indicates a slow database query, external API timeout, or infinite loop.

Best Practices for API Status Codes

Be specific. Use 201 for creation, 204 for deletion, and 409 for conflicts rather than returning 200 for everything. Specific codes make APIs self-documenting.
Include error details. For 4xx errors, return a structured error body with a machine-readable error code, a human-readable message, and the specific field or parameter that caused the error.
Do not leak internals. 5xx responses in production should never include stack traces, database queries, or internal file paths. Log those server-side.
Use Retry-After. For 429 and 503 responses, tell clients when they can retry. This prevents thundering herd problems.
Document your codes. Your API documentation should list every status code each endpoint can return and what each means in context.

Look Up Any Status Code

Our HTTP Status Codes tool provides instant lookup for any status code with descriptions, common causes, and debugging tips. Keep it bookmarked for your next debugging session.

Related Tools

Frequently Asked Questions

401 Unauthorized means the client has not provided valid authentication credentials. The server does not know who the client is. 403 Forbidden means the server knows who the client is (they are authenticated) but they do not have permission to access the requested resource. In short: 401 = "who are you?", 403 = "I know who you are, but you cannot access this."

Use 200 OK for successful GET, PUT, or PATCH requests that return data. Use 201 Created for successful POST requests that create a new resource (include a Location header). Use 204 No Content for successful DELETE requests or updates that do not return a response body.

A 429 status code indicates the client has sent too many requests in a given time period and is being rate-limited. The server should include a Retry-After header. Implement exponential backoff in your client code when you receive 429 responses.

301 Moved Permanently tells browsers and search engines the resource has permanently moved. Search engines transfer SEO value. 302 Found is a temporary redirect where the original URL should continue to be used. Use 301 for domain migrations and 302 for temporary maintenance pages.

Check your server logs for the actual error with stack trace, look for recent deployments, verify database connectivity, check for null pointer exceptions or unhandled edge cases, and test with the same parameters in a development environment where detailed errors are enabled.