HTTP Status Codes Reference: Quick Lookup Guide

What Are HTTP Status Codes

HTTP status codes are three-digit identifiers in server responses that indicate the result of a client's request. Every HTTP response includes a status code telling the client whether the request succeeded, failed, or requires further action. Bookmark our HTTP Status Codes lookup to check any code's meaning in seconds and copy a ready-made response example.

Status Code Categories

1xx: Informational

Indicates the request has been received and further processing is needed.

2xx: Success

Indicates the request was successfully received, understood, and processed.

3xx: Redirection

Indicates the client needs to take additional action to complete the request.

4xx: Client Errors

Indicates the client sent a problematic request.

5xx: Server Errors

Indicates the server failed to fulfill a valid request.

How to Use the HTTP Status Code Tool

Using ToolVault's HTTP Status Codes:

1. Tap a chip in Common status codes (200 / 401 / 404 / 429 / 502, and more) for one-click focus
2. Or search by number, name, or description keyword (e.g. 404, teapot, rate limiting)
3. Filter by 1xx–5xx category to narrow the table
4. Click the copy icon to grab a status line + key headers + sample body for mocks or docs

API Status Code Conventions

RESTful API Convention

// GET /users/123
// Success
200 OK → { "id": 123, "name": "Alice" }
// Not found
404 Not Found → { "error": "User not found" }

// POST /users
// Created
201 Created → { "id": 124, "name": "Bob" }
// Validation failed
422 Unprocessable Entity → { "errors": ["Email is required"] }

// DELETE /users/123
// Deleted
204 No Content → (empty body)

// PUT /users/123
// Not authenticated
401 Unauthorized → { "error": "Token expired" }
// No permission
403 Forbidden → { "error": "Insufficient permissions" }

Don't Abuse 200

Returning 200 OK for all responses is a common anti-pattern:

// ❌ Wrong
res.status(200).json({ success: false, error: "User not found" });

// ✅ Correct
res.status(404).json({ error: "User not found" });

Stuffing business failures into a 200 body breaks monitoring, gateway retries, and shared client error handlers — the status code is the first machine-readable signal.

Debugging by status code: a triage order

When a request fails, the status code tells you where to look before you open a single log file. A practical triage order:

1. 401 → credentials. The token is missing, malformed, or expired. Check the Authorization header first; do not touch server code.
2. 403 → authorization. Credentials are valid but the account lacks permission. This is a policy question, not an auth question — re-issuing tokens will not fix it.
3. 404 → routing. Confirm the path, then confirm the route registration. A trailing slash mismatch and an unregistered route both look like 404.
4. 400 / 422 → payload. Use 400 for malformed syntax; 422 when the body is well-formed but fails validation.
5. 5xx → server side. Only now do you open server logs. 502/504 from a gateway usually mean the upstream process crashed or timed out — check the app before the gateway.

Two confusions account for a surprising share of wasted debugging time: 401 vs 403 (authentication vs authorization) and 404 vs 410 (410 means the resource existed and was deliberately removed — crawlers treat them differently: 404 gets retried, 410 gets de-indexed).

One real-world caveat: status codes you see may be rewritten by intermediaries. CDNs and reverse proxies sometimes convert an upstream timeout into a 502, and some corporate proxies replace 4xx bodies entirely. When the status code and the response body disagree, reproduce with curl -v against the origin to see the raw exchange.

Headers that belong with the status

The tool's Copy response example action follows these conventions so you can paste into OpenAPI samples or local mocks.

FAQ

What's the Difference Between 404 and 410?

404 means the resource might exist but wasn't found (could be temporary). 410 means the resource existed but has been permanently deleted — clients should stop requesting it.

When Should I Use 500 vs 503?

500 is an internal server error (code bug, uncaught exception). 503 means the service is temporarily unavailable (overload, maintenance, dependency failure).

What Should a 429 Response Include?

Include a Retry-After header telling the client when to retry. You can also use X-RateLimit-Reset to return the reset timestamp.

301 vs 308, 302 vs 307?

Permanent redirects: 301 may rewrite POST to GET on older clients; 308 keeps the method. Temporary redirects: 302 may rewrite the method; 307 keeps it. Prefer 307/308 for APIs and form posts so the body is not silently dropped.

Implementation notes

Behind the cheat sheet sits a per-code data table: every status code carries a name, a one-line description, its 4xx/5xx class, and a link to the MDN source — even obscure codes like 407 Proxy Authentication Required that most cheat sheets can't be bothered to include. Descriptions keep exactly one action-guiding sentence; finer semantics are left to the MDN link rather than re-paraphrased.

From the ToolVault developer notebook. The homepage collects more browser-local tools.