Every HTTP response includes a three-digit status code. Most developers know 200 (OK), 404 (Not Found), and 500 (Internal Server Error). But the full range of status codes gives you precise control over how clients, browsers, and crawlers handle your responses.
The five classes
1xx Informational: The request was received, processing continues.
-
100 Continue: The server received the request headers and the client should send the body. Used for large uploads -- the client sendsExpect: 100-continueand waits for confirmation before sending the potentially large body. -
101 Switching Protocols: Used in WebSocket upgrades. The server agrees to switch from HTTP to WebSocket protocol.
2xx Success: The request was received, understood, and accepted.
-
200 OK: The standard success response. -
201 Created: A new resource was created. Used for POST requests that create entities. The response should include aLocationheader pointing to the new resource. -
204 No Content: Success, but no response body. Common for DELETE requests and form submissions where no response body is needed.
3xx Redirection: Further action is needed to complete the request.
-
301 Moved Permanently: The resource has permanently moved. Search engines transfer SEO value to the new URL. Browsers cache this aggressively. -
302 Found: Temporary redirect. The original URL should continue to be used for future requests. SEO value stays with the original URL. -
304 Not Modified: The cached version is still valid. No body is sent, saving bandwidth. -
307 Temporary Redirect: Like 302, but guarantees the HTTP method does not change. A POST redirect stays POST. -
308 Permanent Redirect: Like 301, but guarantees the method does not change.
4xx Client Errors: The request contains an error.
-
400 Bad Request: Malformed request syntax, invalid parameters. -
401 Unauthorized: Authentication required. Despite the name, this is about authentication (who are you), not authorization (what can you do). -
403 Forbidden: Authenticated but not authorized. You proved who you are, but you do not have permission. -
404 Not Found: The resource does not exist. -
405 Method Not Allowed: The HTTP method is not supported for this URL. Sending POST to a read-only endpoint. -
409 Conflict: The request conflicts with the current state. Common for concurrent update conflicts. -
422 Unprocessable Entity: The request is well-formed but semantically invalid. Common for validation errors in APIs. -
429 Too Many Requests: Rate limited. The response should include aRetry-Afterheader.
5xx Server Errors: The server failed to fulfill a valid request.
-
500 Internal Server Error: Generic server failure. Something broke. -
502 Bad Gateway: The server, acting as a proxy, received an invalid response from the upstream server. Common when your application crashes and nginx or a load balancer reports the error. -
503 Service Unavailable: The server is temporarily unable to handle requests. Maintenance mode, overload, or upstream dependency failure. -
504 Gateway Timeout: The proxy did not receive a timely response from the upstream server. Your application is too slow.
The status codes most developers misuse
Using 200 for errors. API responses that return {"error": "not found"} with a 200 status code break HTTP semantics. Clients, monitoring tools, and CDNs rely on status codes to determine response handling. A 200 with an error body gets cached, counted as successful, and passed through proxies without triggering error handling.
Using 302 instead of 301. If a page has permanently moved, use 301. Search engines treat 302 as temporary and may continue indexing the old URL. Years of accumulated SEO value can be lost with the wrong redirect type.
Using 403 instead of 404. Returning 403 for a resource reveals that the resource exists but the user cannot access it. For sensitive resources, returning 404 (pretending it does not exist) is more secure.
I built an HTTP status checker at zovo.one/free-tools/http-status-checker that checks any URL and reports the status code, redirect chain, response headers, and response time. Useful for verifying that your redirects work correctly, that your CDN returns the expected cache status, and that your API responses use appropriate status codes.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)