HTTP Status Codes Reference

HTTP (HyperText Transfer Protocol) status codes are three-digit numbers sent by web servers in response to client requests. They are defined in RFC 7231 (and related specifications) and are organized into five classes indicated by the first digit: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error).



When a browser requests a web page or when an API client makes a call, the server's response always includes a status code. The code tells the client whether the request succeeded, failed, and why. The browser uses these codes to decide what to display (200 = show content, 404 = show error page, 301 = follow redirect, 401 = show login).



Status codes are also critical for web crawlers, search engines, and API clients. Google's Googlebot uses status codes to determine whether pages should be indexed (200), removed from index (404/410), or if the crawler should follow a redirect (301). API clients use status codes for error handling logic—retrying on 503, handling 401 by refreshing tokens, and displaying user-friendly messages for 4xx errors.

1. API Development and Design
REST API designers choose appropriate status codes to communicate results clearly. Using 201 (Created) instead of 200 for successful resource creation, 422 (Unprocessable Entity) for validation errors, and 429 (Too Many Requests) for rate limiting follows established conventions that API consumers expect and can handle automatically.



2. Error Page Configuration
Web servers and CDNs allow custom error pages for specific status codes. Configuring custom 404 pages that suggest related content, 500 pages that apologize and provide support contact, and 503 pages explaining maintenance windows improves user experience during errors.



3. SEO and Search Engine Crawling
Search engine optimization requires understanding how status codes affect indexing. 301 permanent redirects pass "link equity" to the new URL; 302 temporary redirects do not. 404 pages for deleted content should eventually become 301s if the content moved, or 410 (Gone) if permanently removed.



4. Debugging and Monitoring
Application monitoring tools (Datadog, New Relic) track the distribution of HTTP status codes over time. A spike in 5xx errors indicates server problems; increased 4xx errors might indicate a broken link or API change. Understanding codes enables meaningful alerting rules.



5. Security Implementations
Proper use of 401 (Unauthorized) versus 403 (Forbidden) has security implications. 401 indicates authentication is needed; 403 means authenticated but not authorized. Using 403 for non-existent resources (instead of 404) can leak information about what resources exist. Understanding the security implications of status codes is part of secure web development.

• Use 400 for client errors, 500 for server errors: 4xx codes indicate the client made an error (wrong input, missing auth); 5xx codes indicate the server failed. Using the right range communicates responsibility correctly and helps with monitoring.



• Prefer 404 over 403 for security: Returning 404 for unauthorized resources prevents information disclosure—attackers can't enumerate which resources exist by looking for 403 responses.



• Use 301 for permanent redirects: When pages move permanently, use 301. Browsers and search engines cache 301s, so future requests go directly to the new URL. 302 (temporary) is appropriate for genuinely temporary redirects, like maintenance pages.



• Return meaningful error bodies: Status codes alone don't explain what went wrong. Always include a response body with error details for 4xx and 5xx responses, especially for APIs where clients need to handle errors programmatically.



• Don't use 200 for errors: Some older APIs return HTTP 200 with an error message in the body. This breaks standard monitoring tools and forces clients to parse every response body. Return appropriate non-200 codes for error conditions.