HTTP Status Codes Every Developer Should Memorize

I've been debugging web applications for over a decade, and I still watch developers Google "what does 403 mean" multiple times a week. No judgment — there are a lot of status codes. But a handful of them come up so often that memorizing them will save you hours of confusion.

HTTP status codes are the language your server uses to tell clients what happened. Every API response, every page load, every redirect — they all speak in these three-digit numbers. If you don't understand them, you're debugging blind.

This guide covers the codes that matter most in day-to-day development. Not the obscure ones you'll never see — the ones that show up in your logs every single day.

How HTTP Status Codes Work

Every HTTP response includes a status code — a three-digit number that tells the client what happened with their request. The first digit defines the category:

• 1xx — Informational. The request was received, processing continues. You rarely see these in practice.
• 2xx — Success. The request was received, understood, and accepted.
• 3xx — Redirection. The client needs to take additional action to complete the request.
• 4xx — Client Error. The request contains bad syntax or cannot be fulfilled.
• 5xx — Server Error. The server failed to fulfill a valid request.

The 2xx Success Codes

200 OK

The most common status code. The request succeeded. For GET requests, the response body contains the requested resource. For POST requests, it contains the result of the action. Simple, but developers mess this up by returning 200 for error responses — more on that later.

201 Created

The request succeeded and a new resource was created. This is the correct response for a successful POST that creates something — a new user, a new record, a new file.

204 No Content

The request succeeded, but there's no body to return. Perfect for DELETE operations or PUT/PATCH updates where you don't need to send back the updated resource. The response literally has no body — don't try to parse it.

The 3xx Redirection Codes

301 Moved Permanently

The resource has permanently moved to a new URL. Browsers and search engines cache this. Use it when a page URL changes forever — old blog slug, domain migration, URL restructuring.

SEO impact: Link equity transfers to the new URL. Google updates its index.

302 Found (Temporary Redirect)

The resource is temporarily at a different URL. The client should continue using the original URL for future requests. Use it for maintenance pages, A/B testing, or login redirects.

Common mistake: Using 302 when you mean 301. If you're permanently moving a page, use 301. A 302 tells Google "this is temporary, keep the old URL in the index" — which is usually not what you want.

304 Not Modified

The resource hasn't changed since the last request. The client can use its cached version. This is how browser caching works — the server says "nothing changed, use what you have." You'll see a lot of these in your browser's dev tools Network tab.

The 4xx Client Error Codes

These are the most important codes to understand for debugging. A 4xx error means the client did something wrong — bad request, missing auth, wrong URL, etc.

400 Bad Request

The server cannot process the request due to client error — malformed syntax, invalid parameters, missing required fields. This is the catch-all for "your request is wrong."

401 Unauthorized

Authentication required. The request lacks valid credentials. Despite the name "Unauthorized," this is actually about authentication (who are you?), not authorization (what can you do?).

When you see a 401, the fix is usually: send a valid token, refresh an expired session, or log in again.

403 Forbidden

Authorization denied. The server understood your request and knows who you are, but you don't have permission to access this resource. Unlike 401, re-authenticating won't help — you simply aren't allowed.

404 Not Found

The server cannot find the requested resource. The most famous status code. Could mean the URL is wrong, the resource was deleted, or it never existed. Check your URL, your routing configuration, and whether the resource exists in your database.

405 Method Not Allowed

The HTTP method isn't supported for this URL. You sent a DELETE to an endpoint that only accepts GET and POST. The response should include an Allow header listing the valid methods.

409 Conflict

The request conflicts with the current state of the server. Common scenarios: trying to create a user with an email that already exists, updating a record that was modified by someone else (optimistic locking), or deleting a resource that has dependent records.

422 Unprocessable Entity

The request is syntactically correct but semantically wrong. The JSON is valid, but the data doesn't make sense — an age of -5, an end date before the start date, a quantity of zero in an order. Use this instead of 400 when the format is right but the content is wrong.

429 Too Many Requests

Rate limiting. You've sent too many requests in a given time window. The response usually includes a Retry-After header telling you how long to wait. Respect it — hammering a rate-limited API will get your IP banned.

The 5xx Server Error Codes

A 5xx error means the server broke. The client's request was valid, but the server couldn't fulfill it. These are the scariest codes because they usually mean something is wrong with your backend.

500 Internal Server Error

The generic "something went wrong on our end" error. An unhandled exception, a null pointer, a failed database query — anything that crashes your server-side code. When you see this, check your server logs immediately.

502 Bad Gateway

A reverse proxy or load balancer received an invalid response from the upstream server. Usually means your application server crashed or isn't responding. Common with Nginx/HAProxy setups when the backend goes down.

503 Service Unavailable

The server is temporarily unable to handle the request — usually due to maintenance or overload. Unlike 500 (which implies a bug), 503 implies a temporary condition. The server should include a Retry-After header.

504 Gateway Timeout

A reverse proxy or load balancer didn't receive a response from the upstream server in time. Your backend is too slow — a database query is hanging, an external API call is timing out, or your server is overloaded. Check for slow queries, connection pool exhaustion, or external dependency issues.

Real-World Debugging Scenarios

Scenario 1: Login Suddenly Stops Working

User reports they can't log in. What status code do you see?

• 401 → The auth token is expired or invalid. Check token expiration, refresh token logic, or session handling.
• 403 → The user exists but their account is disabled or lacks permissions. Check user status in the database.
• 500 → The auth service crashed. Check server logs for exceptions in your authentication middleware.
• 502/503 → The auth service is down entirely. Check if all services are running.

Scenario 2: API Works Locally But Fails in Production

• 404 → Your route isn't registered in production. Check deployment config, URL rewriting rules, or base path configuration.
• 405 → CORS preflight is failing. The OPTIONS method isn't handled. Check your CORS configuration.
• 500 → Missing environment variable, wrong database connection string, or a dependency that exists locally but not in production.
• 504 → Your database or external API is unreachable from the production network. Check firewall rules and connection strings.

Scenario 3: The Dreaded "200 OK" Error

This is a design anti-pattern where APIs return 200 OK for every response, including errors. The actual error is buried in the response body. This makes monitoring, logging, and debugging significantly harder. If your API does this, fix it. Use proper status codes so that monitoring tools, CDNs, and browsers can handle responses correctly.

Quick Reference: The Must-Know Codes

Key Takeaways

• Memorize the big five: 200, 301, 400, 401, 500. These cover 90% of what you'll encounter daily.
• Know the difference between 401 and 403. Authentication vs. authorization — getting this wrong confuses your API consumers.
• Never return 200 for errors. Use proper status codes so monitoring, caching, and client error handling work correctly.
• 301 vs 302 matters for SEO. Use 301 for permanent moves, 302 for temporary ones.
• 5xx errors mean your server is broken. Check logs immediately — these affect all users, not just one.

Need a quick reference while debugging? Our free HTTP Status Codes tool gives you instant lookup for any status code with descriptions, common causes, and debugging tips. No login required.