HTTP Status Codes Explained: 1xx Through 5xx and How to Diagnose Them

What HTTP Status Codes Are Telling You

Your API returns a 500, your page shows a blank screen, or a form silently fails — and the only clue is a three-digit number. HTTP status codes are the server's short answer to every request, and learning to read them turns guesswork into a diagnosis. This guide walks through the 1xx to 5xx classes, shows you how to check a status code yourself, and explains what each family usually means in practice.

An HTTP status code is a three-digit number a server sends back with every response. The first digit names the class: informational, success, redirect, client error, or server error. The last two digits identify the specific condition. That structure matters, because it tells you where to look first — at the request, the network, or the server.

If you need to inspect a live response right now, a browser-based HTTP header and status checker will show the code, the headers, and the redirect chain without installing anything.

The Five Classes of HTTP Status Codes at a Glance

Before the details, here is the map. Every code you will meet belongs to one of five families.

• 1xx — Informational. The server received the request and is still working. These are rare in normal browsing.
• 2xx — Success. The request worked. The most common is 200.
• 3xx — Redirection. The resource moved. The client needs to follow a new location.
• 4xx — Client error. Something about the request is wrong: a bad URL, missing credentials, or a malformed body.
• 5xx — Server error. The request looked fine, but the server failed to fulfil it.

The class tells you who is responsible. A 4xx means the request needs fixing. A 5xx means the server does.

What Do the 1xx and 2xx Codes Mean?

The 1xx class is informational and mostly invisible. A 100 Continue tells a client to send the rest of a large request body. A 101 Switching Protocols confirms an upgrade, such as moving a connection to WebSocket. You rarely handle these directly.

The 2xx class is where successful traffic lives. The codes you will actually see:

• 200 OK — the standard success response.
• 201 Created — a new resource now exists, common after a POST.
• 204 No Content — success with an empty body, often used after a DELETE.
• 206 Partial Content — a range of the resource was returned, used for resumable downloads and media streaming.

A 204 is not an error. If your client expects a body and gets none, that is a client-side parsing problem, not a server failure.

What Do the 3xx Redirect Codes Mean?

Redirects tell the client the resource lives somewhere else. A 301 Moved Permanently signals a lasting move and is cacheable. A 302 Found is a temporary redirect. A 307 Temporary Redirect and 308 Permanent Redirect preserve the original request method, which matters for POST requests that a 301 or 302 might otherwise convert to GET.

Redirect chains are a common performance trap. Each hop adds a round trip. If a page passes through three redirects before loading, you have paid for four requests. Use a redirect checker to see the full chain and collapse it where you can.

Client Errors: The 4xx Family

A 4xx means the server understood the request but refused it. The request is the problem.

400 Bad Request

The server could not parse the request — malformed JSON, a missing required field, or an invalid header. Check the request body and headers first.

401 Unauthorized and 403 Forbidden

These two are often confused. A 401 means authentication is missing or invalid: the server does not know who you are. A 403 means the server knows who you are but you lack permission. Fixing a 401 means supplying credentials. Fixing a 403 means changing permissions.

404 Not Found

The resource does not exist at that URL. For a website, check the link or the route. For an API, confirm the endpoint path. A 404 is not a server fault.

429 Too Many Requests

You have hit a rate limit. The response usually includes a Retry-After header telling you how long to wait. Back off and retry rather than hammering the endpoint.

How to Diagnose Server Errors in the 5xx Family

A 5xx means the request was valid but the server failed. These are the hardest to fix because the fault is usually not yours.

500 Internal Server Error

A catch-all. The server hit an unexpected condition and could not say more. Check server logs — the specific cause is almost always recorded there.

502 Bad Gateway and 504 Gateway Timeout

A 502 means an upstream server returned an invalid response to a gateway or proxy. A 504 means the upstream server did not respond in time. Both point at the layer behind the gateway, not the client.

503 Service Unavailable

The server is overloaded or down for maintenance. It is often temporary, and a Retry-After header may tell you when to try again.

How to Check an HTTP Status Code: Step by Step

You can read a status code without any special software. Here is the general process.

1. Identify the exact request. Note the full URL, the HTTP method (GET, POST, and so on), and any headers or body you are sending.
2. Send the request and capture the response. Browser developer tools show the status in the Network tab. For a quick check outside a page load, a status code checker returns the code and headers directly.
3. Read the class first. The first digit narrows the cause to the client, the server, or a redirect.
4. Read the specific code. Match it to the tables above to find the likely cause.
5. Check the response headers. Location explains redirects. Retry-After explains rate limits and outages. WWW-Authenticate explains a 401.
6. Reproduce with a minimal request. Strip the request down until it either succeeds or fails predictably. This isolates whether the fault is in your input or the server.
7. Confirm the fix against the same request. Re-send and verify the code changed to the 2xx you expect.

If you are testing many endpoints, an online HTTP request tool lets you send requests and inspect responses in one place. It runs in your browser, so nothing is installed and no request data is stored beyond your session.

Why the Same Code Can Mean Different Things

A status code is a convention, not a guarantee. Servers sometimes return 200 with an error message in the body, which breaks clients that trust the code alone. Others return 404 for a resource that exists but is hidden, to avoid leaking its presence.

The practical rule: treat the status code as the primary signal, but read the body and headers when the code does not match the outcome. When you build an API, return the code that honestly describes what happened. Clients depend on it.

Frequently Asked Questions

What is the difference between 401 and 403?

A 401 means you are not authenticated — the server does not know who you are, so supply valid credentials. A 403 means you are authenticated but not permitted to access the resource. The fix differs: a 401 needs a login or token, a 403 needs a permission change.

Is a 3xx redirect an error?

No. A redirect is a normal response telling the client the resource moved. It only becomes a problem when redirects chain, slow the page, or loop endlessly. Check the chain and remove unnecessary hops.

Can a 200 response still contain an error?

Yes. Some servers return 200 with an error message in the body. This is poor practice because clients that check only the status code will treat the failure as success. Always read the body when the outcome looks wrong.

What should I do about a 500 error I cannot reproduce?

Check the server logs first — the cause is usually recorded there. If you have no log access, capture the full request and response, including headers, and report it. A 500 is a server-side fault, so the fix is on the server.

How often should I check status codes on my own site?

Check them whenever you change routes, links, or server configuration, and periodically to catch link rot. Automated checks catch redirect chains and 404s before visitors do.

Reading Status Codes with Confidence

Once you can place a code in its class, most debugging collapses into a short list of likely causes. The first digit tells you who is at fault, the specific code narrows it down, and the headers fill in the rest. Treat HTTP status codes as the server's own account of what happened, and you will spend less time guessing and more time fixing. When you need to inspect a live response, a browser-based tool gives you the code and headers in seconds.