What a status code tells you
When a browser requests a page, image, or other resource, the server sends back an HTTP response. Its three-digit status code gives a short account of the result. The first digit identifies the family: 1xx is informational, 2xx indicates success, 3xx calls for a further step, 4xx indicates a problem with the request, and 5xx indicates a server-side failure.
A status code is a starting point, not a complete diagnosis. The response headers, any response body, and the request that produced it provide useful context. For example, a page might load while one of its images returns an error. To understand what happened, inspect the status of the specific request you care about rather than relying only on what appears in the browser window.
1xx and 2xx: progress and success
A 1xx response conveys information while a request is being handled. Beginners rarely need to act on one directly, but the family matters because not every status code describes a finished request. A final response follows an informational one.
A 2xx response means the request succeeded, though different codes describe different outcomes. 200 OK commonly accompanies a successful page or data response. 201 Created indicates that a new resource was created. 202 Accepted means the request was accepted for processing, not necessarily that the work is complete. 204 No Content indicates success without a response body. If your code expects JSON from every successful request, a 204 response is a reminder to check the status before attempting to parse a body.
3xx: another step may be needed
A 3xx response often tells a client where to go next. A server might redirect an old page address to a new one, for instance. Common redirect codes include 301 Moved Permanently, 302 Found, 307 Temporary Redirect, and 308 Permanent Redirect. The distinction can matter when a request has a method such as POST: 307 and 308 specify that the client should preserve the method when following the redirect. Many browsers follow redirects automatically, so the address or page you see may be the result of several requests.
Not every 3xx code sends you to another address. 304 Not Modified is used in connection with caching: it tells the client that a stored copy can still be used under the conditions of the request. When investigating a surprising response, look at the request history and relevant headers. A 3xx code alone does not tell you whether a redirect led to a working destination.
4xx and 5xx: identifying the kind of failure
A 4xx code indicates that the server cannot fulfill the request as sent. 400 Bad Request suggests a problem with its format or contents. 401 Unauthorized generally means authentication is needed or has failed; 403 Forbidden means the server refuses access. 404 Not Found means the requested resource was not found at that address. 429 Too Many Requests signals that requests are being limited. These codes suggest different next checks: the URL, request data, credentials, permissions, or request frequency.
A 5xx code indicates that the server failed to fulfill a request it might otherwise have handled. 500 Internal Server Error is a general server failure. 502 Bad Gateway and 504 Gateway Timeout involve a server acting as a gateway and encountering trouble with another server; 503 Service Unavailable indicates that the service is temporarily unable to handle the request. A 5xx response does not, by itself, reveal the exact fault. If you maintain the service, logs and the surrounding request details are more useful than guessing from the code alone.
Inspect a status in your browser
You can practice with the developer tools built into a modern desktop browser; no separate package or particular browser version is required for this exercise, although menu names may vary. Open a page, open Developer Tools, select the Network panel, and reload the page. Choose a request to see its status, request URL, response headers, and, where present, response body. If the list is crowded, select the main page request first, then compare it with requests for scripts or images.
Try asking three questions in order: What resource was requested? What status did that request receive? What do the headers and response show? For a redirect, inspect both the redirecting response and the request to its destination. For an error, check whether you are looking at the page itself or one of its supporting resources. This small routine turns a status code from a vague label into a useful debugging clue.
