HTTP Status Code Lookup

An HTTP status code is the three-digit number a server sends back to tell you how your request went. 404 means the page wasn't found, 200 means it worked, 500 means the server broke. Most reference lists stop there and leave you to do the digging. This one does the annoying part for you. Paste the thing you're actually looking at, a curl line, a log row, a fetch error, even a full raw response, and it pulls the code straight out and tells you what it means. Or type a bare number like 403, or a plain word like "forbidden". It all runs in your browser, so nothing you paste is uploaded or stored anywhere.

When something breaks, you rarely have a clean number to look up. You've got a wall of curl output, or a log line like GET /api/orders 502 in 1.4ms, or a red error in the console. Most references make you find the number yourself and retype it. This one reads the line and spots the 502, or the 429, whatever is buried in there. That's the part I always wanted when I was staring at a broken API, and almost nobody builds it.

1. Type a code. Enter 404, 429, or 301 and the match appears with its name and meaning. Partial numbers work too, so 40 surfaces the whole 400 to 409 range.
2. Paste a line or a log. Drop the curl output, access-log row, or raw response into the box and it scans the text for real status codes and surfaces them. No need to clean it up first.
3. Search by a word. Can't remember the number? Type what you saw. "not found", "too many requests", "gateway", "forbidden". It matches on every code's name and description.
4. Filter by class. The 1xx through 5xx buttons narrow the list to one group, handy for seeing every redirect code, or all the server errors, in one view.
5. Copy the meaning. Each result has a copy button that grabs the code, its name, and the plain explanation, ready to paste into a ticket or Slack.
6. Share the exact view. The Share button copies a link that reopens your current search and filter, so you can send a teammate straight to 422 instead of telling them to look it up.

There's no run button. It filters live as you type, and it keeps working offline once loaded.

The first digit is the whole trick. Learn what each leading number means and you can read a code you've never seen.

1xx Informational. The request arrived and the server is still working. Provisional handshake messages you almost never see, like 100 Continue and 101 Switching Protocols (the WebSocket upgrade).

2xx Success. Received, understood, and accepted. 200 OK is the one you want, with 201 Created and 204 No Content covering more specific wins.

3xx Redirection. What you asked for lives somewhere else, or your cached copy is still good enough. Redirects like 301 and 302 sit here, along with cache replies like 304.

4xx Client error. Something about your request was wrong. A typo in the URL, a missing token, a method the endpoint doesn't allow. It's where you hit 400 for a request the server can't even parse and 422 when your JSON is valid but fails a validation rule. The fix is on your side, and this is the class worth knowing best.

5xx Server error. Your request was fine but the server fell over handling it. A crash, an overloaded database, or a dead upstream. Usually there's nothing you can do but wait or tell whoever runs it.

This pair trips people up, and getting it wrong quietly costs you search rankings. A 301 says the move is permanent. Search engines take that as an instruction to drop the old URL, index the new one, and carry the accumulated link authority over to the new address. That last part is the whole reason it matters. A 302 says the move is temporary, so search engines keep the original URL in their index and pass no authority along, because as far as they know the old one is coming back.

So the costly mistake is using a 302 for a change that is actually permanent. You end up telling Google to keep the dead URL and pass no credit to the live page, and rankings stall for a reason nobody spots until they check the redirect type. If the move is permanent, use 301. Reach for 302 only when it really is temporary. One catch for developers, 301 and 302 have a messy history with POST requests, and some browsers switch the method to GET on the way through. If the method and body must survive untouched, use 308 for permanent or 307 for temporary.

Both mean you can't have the thing, but for different reasons, and the reason tells you what to try next. A 401 means the server does not know who you are. You sent no credentials or bad ones, so log in, refresh your token, or add the auth header. A 403 means the server knows exactly who you are and is still saying no. You're authenticated fine, you just lack permission, and signing in again changes nothing. Quick test, if logging in again might fix it, it's a 401. If you're already in and still blocked, it's a 403. Some sites even return a 404 instead of a 403 on purpose, so an attacker can't confirm the resource exists at all, which is an intentional security decision rather than a malfunction.