HTTP status codes are like the server sending you a quick text back when you’re building websites or apps. Every time your browser or app asks for something, the server replies with a three-digit number that tells you if everything worked, something went wrong, or you need to do something else.
Knowing these codes helps you fix problems faster, keep an eye on your app, and make sure it works reliably.
Before we get started, don’t forget to subscribe to my newsletter!
Get the latest tips, tools, and resources to level up your web development skills delivered straight to your inbox. Subscribe here!
What Are HTTP Status Codes?
In simple terms, HTTP status codes are the server’s way of replying to your browser, app, or other services. They’re like little signals that tell you what happened after your request.
The first number of the three-digit code shows the type of response:
- 1xx: Informational (The server got your request and is still working on it, rarely seen.)
- 2xx: Success (Everything worked! This is what you want to see.)
- 3xx: Redirection (The resource has moved, so follow the new link.)
- 4xx: Client Errors (Something’s wrong with your request. Check your input.)
- 5xx: Server Errors (The server tried but failed to complete the request.)
Common HTTP Status Codes
These are the HTTP status codes you’ll see most often while building web apps and APIs.
200: OK
You receive this when everything worked fine, when a page loads, an API call returns data, or a form submits successfully.
201: Created
You receive this when the request creates something new, which means registering a new user or posting content via API.
301: Moved Permanently
A permanent change of address when your site gets a domain change or URL cleanup.
302: Found (Temporary Redirect)
This is used when you want to temporarily move users, but the original URL is still valid. Like for maintenance pages, temporary promos, or A/B testing.
400: Bad Request
This happens when the server can’t understand the request. Usually because of syntax or invalid data, malformed JSON, or missing parameters.
401: Unauthorized
This code is received when you’re not logged in or your credentials are missing. Like if the token has expired, or invalid API key.
403: Forbidden
This happens when the user is logged in, but they don’t have permission. For example, if a regular user tries to access admin routes.
404: Not Found
The classic. Resource doesn’t exist. When there are broken links, deleted pages, or typos in the URL.
418: I’m a Teapot ☕
Yes, this is real. Added as an April Fools’ joke in RFC 2324, it means the server refuses to brew coffee because it’s a teapot.
Mostly used for fun in APIs or Easter eggs, but a reminder that developers have a sense of humor too.
429: Too Many Requests
You’ll receive this when you’re sending requests too quickly. For example, hitting API rate limits or aggressive scraping.
500: Internal Server Error
This means something broke on the server. When there are unhandled exceptions, DB connection issues, or misconfigured servers.
502: Bad Gateway
This means the middleman messed up. This happens when the proxy server, load balancer, or microservice communication fails.
503: Service Unavailable
This means the server is overloaded or under maintenance during downtime, updates, or a temporary server overload.
Best Practices for Using HTTP Status Codes
- Always use the right code. Don’t just stick to 200 or 500 for everything. For example:
- 201 → Resource created,
- 204 → Success, but no content to return,
- 422 → Validation errors (like wrong input),
- 409 → Conflicts (like a duplicate username)
- Be consistent. If you use a code like 422 for validation errors in one API, use it everywhere in your APIs.
- Add helpful messages. Status codes tell the type of response, but always include a short message that explains why it happened.
- Monitor your status codes.
- Spikes in 500s → Server problems
- Rising 404s → Broken links or missing pages
Wrapping Up
HTTP status codes aren’t just numbers, they’re the server’s way of talking to you. Understanding them can save you a lot of time when debugging and help you build more reliable apps.
And yes, if you ever see 418, don’t panic, it’s just a teapot refusing to make coffee. ☕
Next time you see a 200, 404, or 500, you’ll instantly know what the server is trying to tell you!
That’s all for today!
For paid collaboration connect with me at : connect@shefali.dev
If you enjoy my work and want to support what I do:
👉 Become a Patreon supporter
👉 Or buy me a coffeeEvery small gesture keeps me going! 💛