Developer
HTTP Status Codes Explained (200, 404, 500)
Every HTTP response from a server includes a three-digit status code that tells your client whether the request succeeded, failed, or needs further action.
What Are HTTP Status Codes?
HTTP status codes are three-digit numbers that a web server includes in every response to signal the outcome of a request. When your browser fetches a webpage or your app calls an API, the server responds with a status code that tells you whether everything worked, something went wrong, or you need to do something else.
These codes are grouped into five classes, each with a different meaning. The first digit indicates the class: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error). Understanding these categories helps you diagnose problems faster and know whether to retry a request, change your approach, or report a bug.
The HTTP specification defines status codes as part of the protocol itself, so they work the same way across all web servers, browsers, and APIs. Whether you're building a REST endpoint, a web scraper, or debugging a mobile app, you'll encounter these codes constantly.
2xx Status Codes: Success
When a status code starts with 2, the request succeeded. The server processed your request correctly, found the resource, executed the action, or all of the above.
200 OK is the most common. It means the request was successful and the response body contains the data you asked for—a webpage, JSON from an API, an image, or whatever you requested. Most successful web requests return 200.
201 Created signals that a new resource was created as a result of your request. This typically appears when you POST to create a new database record, upload a file, or submit a form that generates a new object. The response usually includes the new resource's details or a Location header pointing to it.
204 No Content means the request succeeded, but there's no response body to send back. This is common for DELETE operations or PUT requests that don't need to return anything. The server processed it successfully; there's just nothing to display.
Other 2xx codes you might encounter: 202 Accepted (the request is queued for processing), 206 Partial Content (you requested a byte range of a file), and 205 Reset Content (refresh the form you just submitted). In practice, 200 and 201 cover most cases.
3xx Status Codes: Redirection
A 3xx code tells the client that further action is needed to complete the request. Usually, the browser or HTTP library handles these automatically by following the redirect.
301 Moved Permanently means the resource is now at a different URL, and all future requests should use the new location. If you move a blog post to a different path, you'd return 301 from the old URL to tell search engines and clients to update their bookmarks. The response includes a Location header with the new URL.
302 Found (also called Temporary Redirect) is similar to 301, but signals that the move is temporary. The original URL might come back. A server might return 302 during maintenance or when redirecting users to a login page before they can access a resource.
304 Not Modified is a clever optimization. If your browser asks for a resource it has cached, and includes metadata about the cached version (an ETag or Last-Modified header), the server can respond with 304 to say your cached copy is still current. The browser uses the cached version, saving bandwidth.
307 Temporary Redirect and 308 Permanent Redirect are modern versions of 302 and 301 that preserve the HTTP method. If the original request was a POST, they guarantee the client will POST again to the new location, not downgrade to GET. This matters when form submissions or API calls are redirected.
4xx Status Codes: Client Error
A 4xx code means the client made a mistake—the request was malformed, unauthenticated, forbidden, or asked for something that doesn't exist. The server is saying: this isn't my problem, fix your request.
400 Bad Request is a generic client error. The server couldn't understand the request because the syntax was invalid, the JSON was malformed, required fields were missing, or the body format was wrong. When you're debugging an API call and see 400, check your request headers, body, and parameters.
401 Unauthorized means you're not authenticated. You didn't provide valid credentials, your login token expired, or your session isn't recognized. Redirect the user to log in and retry after authentication.
403 Forbidden means you're authenticated but not authorized. You have a valid login, but your account doesn't have permission to access this resource. An admin endpoint might return 403 if a regular user tries to access it, even if they're logged in.
404 Not Found is probably the most recognizable. The server looked for the resource at that URL and didn't find it. The page was deleted, the URL is wrong, or the API endpoint doesn't exist. Don't assume 404 means the server is broken; it usually just means you asked for the wrong thing.
405 Method Not Allowed means you used the wrong HTTP method. You tried to POST to an endpoint that only accepts GET, or tried to DELETE a resource that can't be deleted. Check the API documentation or the Allow header in the response.
429 Too Many Requests (rate limiting) tells you that you're sending requests too fast. The server has a rate limit and you've exceeded it. Back off and retry after a delay, which the server usually specifies in the Retry-After header.
5xx Status Codes: Server Error
A 5xx code means the server messed up. Your request was probably fine, but the server encountered an error while trying to process it. These are server problems, not client problems.
500 Internal Server Error is the catch-all. Something went wrong inside the server—an unhandled exception, a database connection failure, or a bug in the application code. It tells you the problem is on the server side, but usually not much more detail. Check server logs to debug.
502 Bad Gateway appears when you're accessing a website through a reverse proxy or load balancer, and that proxy can't reach the backend server. The proxy is working, but the actual application server is down or unreachable. This is common when servers are restarting or experiencing network issues.
503 Service Unavailable means the server is temporarily unable to handle the request. The server might be overloaded, undergoing maintenance, or restarting. Clients should retry after some time, which the server indicates in the Retry-After header.
504 Gateway Timeout occurs when a reverse proxy or gateway waits too long for a backend server to respond and gives up. The backend server is probably slow or hung. This is different from a 500; it's a timeout, not an error within the application.
Other 5xx codes include 501 Not Implemented (the server doesn't support the requested method) and 505 HTTP Version Not Supported (the server doesn't understand the HTTP version you're using). In practice, 500, 502, and 503 cover most server-side problems you'll encounter.
How to Use Status Codes in Your Code
When you build a web API or server, you choose the right status code to send back. Return 200 for successful reads, 201 for successful resource creation, 400 for invalid input, 401 when authentication is missing, 403 when permission is denied, 404 when the resource doesn't exist, and 500 for unexpected errors.
In JavaScript, when you use fetch() or a library like axios, you can check the status code and branch your logic. A fetch response's ok property is true for 2xx codes and false for anything else, so you can write if (response.ok) to check for success. For APIs, examine response.status directly to handle specific codes like 404 or 429.
Use the status code to guide error handling and UX. Show a generic error message for 5xx codes and invite the user to retry. For 4xx codes like 400 or 403, show specific, actionable messages: tell the user what's wrong with their input or why they're not allowed. Never expose raw error messages to end users.
Pay attention to the Content-Type header and response body format, especially when interpreting error codes. An API might return JSON with error details, while a webpage returns HTML. Check the MIME Types reference to understand what format to expect based on the Content-Type header.
Common Mistakes and Debugging Tips
Mistake 1: Returning 200 for everything. Some developers return 200 even when something fails, putting the error inside the response body as a custom field. This breaks HTTP semantics and makes it harder for tools, proxies, and clients to understand success vs. failure. Use the correct status code; reserve the body for details.
Mistake 2: Confusing 404 and 400. A 404 means the resource doesn't exist. A 400 means the request was malformed or invalid. If someone requests /users/abc and abc isn't a valid ID, that's a 400 (bad request syntax). If they request /users/123 and user 123 doesn't exist, that's a 404 (not found).
Mistake 3: Not retrying on 5xx codes. If you see a 500 or 503, the problem is temporary in many cases. A smart client will retry with exponential backoff, waiting longer between each attempt. For 429 (rate limit), always respect the Retry-After header.
Debugging tip: Use browser developer tools (F12) and check the Network tab to see status codes for every request. Most API clients and testing tools like curl or Postman display the status code prominently. When a request fails, the status code is your first clue about what to fix.
Frequently asked questions
What's the difference between 404 and 410?
404 Not Found means the server can't find the resource right now, but it might exist later. 410 Gone means the resource is permanently deleted and will never come back. Use 410 when you want to signal that something is intentionally gone; use 404 when you're unsure.
Why would a server return 200 for a failed login instead of 401?
Sometimes servers return 200 with a JSON error message to avoid leaking whether a username exists. This is intentionally obscure for security. Well-designed APIs return 401 or 403 to be clear and let clients handle authentication and authorization properly.
What should I do if I see a 502 or 503 error?
These are temporary server problems. Refresh the page in a few seconds, or if you're making API calls, wait and retry with exponential backoff. If the error persists for hours, contact the service provider; there might be a real outage.
Can I rely on the status code alone to know if my request worked?
Mostly, yes. For APIs and web services, the 2xx status codes reliably signal success. Always check the status code first before trying to parse the response body, especially for error responses which may have different formats.
What's the point of 204 No Content if 200 OK also works?
204 is more explicit. It tells the client: success, and there's definitely no body coming. This helps clients optimize (don't wait for a body) and makes intent clear. Use 204 for DELETE or operations where no data needs to be returned.
How do I know if a status code will be cached by my browser?
By default, 200, 203, 204, 206, 300, 301, 404, 405, 410, and some others are cacheable based on Cache-Control headers. 404 is often cached to avoid repeated requests to missing resources. Check the Cache-Control and Expires headers to understand caching behavior.