HTTP Status Codes: A Complete Guide to 1xx, 2xx, 3xx, 4xx, and 5xx

Imagine driving through a sprawling digital city, sending requests from one server to another. Every time you click a link, submit a form, or fetch an API, you are knocking on a door. The response you get back, that three‑digit number, is the digital equivalent of a shopkeeper shouting back at you. Is your order ready? Is the shop closed? Did you walk into the wrong store? Or did the entire building just collapse?

HTTP status codes are the universal language of the web. They tell you, in a single glance, exactly what happened to your request. While the internet throws around 404 like a pop‑culture meme, the truth is there are over sixty standardized status codes, and mastering them is non‑negotiable for any serious developer, DevOps engineer, or SEO specialist.

In this comprehensive guide, we break down every class of status codes from the silent whispers of 1xx to the catastrophic explosions of 5xx, so you can diagnose, fix, and optimize your web applications like a pro.

Informational Responses (1xx)

The 1xx class indicates that the server has received the request headers and the client should proceed to send the request body (or continue waiting). These codes are rarely seen in production but are essential for protocol negotiation.

100 Continue

This interim response indicates that the server has received the initial part of the request and the client should continue sending the remainder. It is typically used when a client sends an Expect: 100-continue header and the server agrees to accept the payload.

101 Switching Protocols

Sent when the client asks the server to switch to a different protocol (for example, upgrading from HTTP/1.1 to WebSocket). The server agrees and sends this code to acknowledge the change.

102 Processing

A rarely seen code indicating the server has accepted the full request but has not yet completed it. This prevents the client from timing out while waiting for a long‑running operation.

Success Codes (2xx)

This is what you want to see every single time. The 2xx class means the server successfully received, understood, and accepted the request.

200 OK

Think of it like ordering a pepperoni pizza with extra cheese, and it shows up exactly like that, hot and perfect. In the development world, this happens when you fetch a user profile and get back clean JSON with their name, email, and avatar. Grab that data, render it in your UI, and keep moving. This is the most common success code in API responses and web browsing.

201 Created

This code means you did not just succeed, you created something new. Typically returned after a successful POST request, a 201 confirms that a new resource has been born on the server. This happens when creating new user accounts, inserting database entries, or publishing forum posts. The cool part: the server often sends a Location header with the exact address of what you just created. When you see 201, always check that header; it is your direct link to your brand‑new resource.

204 No Content

Success with a twist: no response body. The server completed your task, maybe you deleted a user, updated a record, or modified a setting, but there is nothing to send back. A 204 often follows DELETE, PATCH, or PUT operations where confirmation of success is all you need.

Redirection Codes (3xx)

These codes indicate that the client must take additional action to complete the request. They are the road signs of the internet, telling your browser where to go next.

301 Moved Permanently

When you see a 301, it means one thing: this resource has permanently moved. Update your bookmarks. The browser automatically redirects to the new URL. This code is vital for SEO; by using a 301, the old URL’s search engine ranking power (link juice) is passed to the new URL. It is the digital equivalent of submitting a permanent change of address form to the post office.

302 Found (Temporary Redirect)

Unlike a 301, this move is short‑term. The original URL will be back. The server is saying, “I am making a temporary detour. The content is over here right now, but please keep using my original URL for all future requests.” This often happens during server maintenance or A/B testing. A 302 tells search engines not to update their records or pass along SEO value.

303 See Other

This is a specific instruction: “The response to your request can be found elsewhere, but you must use the GET method to fetch it.” This is the internet’s way of preventing the dreaded “Confirm Form Resubmission” popup. If you submit a POST request and the server sends a 303 redirecting you to a “Thank You” page, the browser will follow that redirect with a GET request. Your form will not be re‑submitted when the user refreshes.

307 Temporary Redirect

Similar to 302, but with a critical difference: the request method is not allowed to be changed when reissuing the original request. A POST request must be repeated as another POST to the new location.

308 Permanent Redirect

Similar to 301, but does not allow changing the request method from POST to GET. When a POST request encounters a 308 redirect, the browser repeats that POST to the new location with the original payload intact.

304 Not Modified

This is a silent success story working behind the scenes. When your browser visits a page, it asks the server, “Has this file changed since the last time I downloaded it?” If the content has not changed, the server replies with a 304. It says, “Use the version you already have in your cache.” This drastically speeds up page loading and saves bandwidth.

Client Errors (4xx)

We have reached the dreaded 4xx class. The server understands the request, but it is not going to process it because you (the client) messed up. The problem lies in the URL, the payload, the authentication, or the permissions.

400 Bad Request

The server understood your request, but it is malformed or invalid. Think of it like trying to order a coffee by shouting “Liquid hot refresh things!” The barista understands you want a drink, but not what kind. Common causes: bad URL syntax, malformed JSON (missing a comma), missing required fields, or corrupted cookies.

401 Unauthorized

The server tells you, “I know who you are trying to be, but you have not given me proper credentials.” It is all about identity. Did you log in? Is your session token expired? Is your username or password wrong? Fix your credentials and you are usually good to go.

403 Forbidden

One of the most misunderstood codes. Think of it this way: 401 means “Show me your ID.” 403 means “Your ID is valid, but you do not have the key to this room.” You are authenticated, but you lack the necessary permissions or roles for that specific resource.

404 Not Found

The most famous error of them all. The server checked its entire directory and came up empty. The resource does not exist. This can happen because the page was deleted, the website was restructured, or most commonly, you have a typo in the URL.

405 Method Not Allowed

This one is for API developers. The resource exists, but the HTTP method you tried to use on it is invalid. For example, you might try to POST a new item, but that endpoint only allows GET. Check your API documentation.

413 Payload Too Large

The server refuses to process your request because the payload you sent exceeds the server’s acceptable size limit. This often happens when you attempt to upload massive videos or large datasets.

414 URI Too Long

The server refuses to process the request because the URL you provided is excessively long, often due to massive query strings.

415 Unsupported Media Type

The server refuses to accept the request because the content format is not supported. Did you send JSON when the server expected XML? Did you forget the Content-Type: application/json header?

422 Unprocessable Entity

This is nuanced: the server understands the content type and the syntax is correct (so a 400 would be inappropriate), but it cannot process the contained instructions due to semantic errors. For example, well‑formed JSON with an email field that says “notanemail” will trigger this.

426 Upgrade Required

The server refuses to perform the request using the current protocol and sends an Upgrade header telling you which protocol to use (often HTTP/2 or WebSockets).

429 Too Many Requests

This is the server’s way of telling you to slow down. You have hit the rate limit. Servers do this to prevent abuse and keep things fair. The server may send a Retry-After header with the number of seconds to wait.

451 Unavailable For Legal Reasons

A modern addition indicating that the server cannot deliver the requested resource due to legal actions, such as court orders, copyright claims, or government censorship.

Server Errors (5xx)

Finally, we reach the 5xx class. These codes mean the problem is not with your browser or your request; it is on the server’s side. The server is aware it has messed up.

500 Internal Server Error

The catch‑all error. It is the server’s way of saying, “Something unexpected broke, and I do not know how to describe it better.” This often happens due to unhandled exceptions, database connection failures, or misconfigured server settings. Imagine walking into a store ready to check out, but the cashier’s register suddenly crashes. They want to help you, but first they need to fix their system.

501 Not Implemented

The server does not support the functionality required to fulfill the request. For example, if your client sends a DELETE request to a static file host that only supports GET and HEAD, it will return a 501. (Servers are required to support GET and HEAD.)

502 Bad Gateway

This means a middleman server (a gateway or proxy) received a bad response from another server it relies on. This happens constantly in microservice architectures where servers form a chain. Your request hits Server A, which asks Server B for help, but Server B is having a meltdown.

503 Service Unavailable

The server is alive and gets your request, but it is currently unavailable, either overwhelmed by traffic or taken offline for maintenance. Often, you will see a Retry-After header with an exact comeback time.

504 Gateway Timeout

Similar to 502, but the upstream server gave no response at all in time. The gateway timed out waiting for the upstream server to finish its work.

505 HTTP Version Not Supported

The server does not support the HTTP version used in your request. This can happen if a misconfigured client sends a malformed request line or uses a future version of HTTP that the server has not adopted yet.

Example Workflow: Handling a Rate‑Limited API

Conclusion: Speaking the Web’s Native Language

The difference between a frustrated user refreshing a page repeatedly and a calm developer fixing a root cause in minutes often comes down to understanding HTTP status codes. They are the diagnostic dashboard of the internet.

• Check the class first: 2xx (Good), 3xx (Go there), 4xx (Fix your input), 5xx (Wake up the SysAdmin).
• Always check the headers: For 201, look at Location. For 429 and 503, look at Retry-After.
• Remember the nuance: Do not confuse 401 with 403, or 302 with 307.

Next time you hit an error, stop and read the code. It is not just a number; it is the server talking to you directly. Listen to it, and you will spend less time debugging and more time building.

For further reading, refer to the official MDN HTTP status documentation and the HTTP/1.1 specification (RFC 9110).