Developer

HTTP Status Codes

A fast, searchable table of common RFC 9110–style codes (1xx–5xx) plus a few widely seen non-standard responses (nginx, Cloudflare). Filter by series, search by number or phrase, and click a row to copy — everything runs in your browser with no server round-trips.

Ad placement — top banner
Series
Click any row to copy code, phrase, and short meaning.
Code Reason phrase Meaning
Ad placement — mid rectangle

What are HTTP status codes?

Every HTTP response includes a three-digit status code that classifies the outcome: informational (1xx), success (2xx), redirection (3xx), client error (4xx), or server error (5xx). APIs, browsers, CDNs, and proxies all rely on these codes — along with headers and bodies — to decide caching, retries, and error handling.

How this reference is organized

The table lists IANA-registered semantics as described in RFC 9110 (HTTP semantics), including WebDAV-related codes where they are commonly encountered. A small Extensions filter covers non-standard codes you may see in nginx or Cloudflare edge responses — they are labeled Non-standard in the table.

  • 1xx — provisional responses while the request is still in flight.
  • 2xx — the request was understood and accepted.
  • 3xx — further action at the client (usually a redirect).
  • 4xx — the client should change the request or cannot access the resource.
  • 5xx — the server or gateway failed after accepting the request.

REST, APIs, and mobile clients

When you build REST or mobile backends, pairing the right status with a clear error body (problem+json, JSON errors, or protobuf) matters as much as the number itself. Use 4xx for caller-fixable issues (validation, auth, not found) and 5xx for failures after the request reached your app logic or upstream dependencies.

Reason phrases vs. the numeric code

In HTTP/1.1 the textual reason phrase appears on the status line; in HTTP/2 and HTTP/3 the code is carried in binary frames without that phrase. Intermediaries may normalize or omit wording — clients should rely on the numeric code and response headers, not exact phrase text.

How to use this tool

  1. Step 1: Type in the search box or pick a series (1xx–5xx, or Extensions).
  2. Step 2: Click a row to copy code, phrase, and a one-line explanation.
  3. Step 3: Use Copy visible (TSV) to paste into spreadsheets or docs for the filtered set.

Frequently Asked Questions

Does this tool send HTTP requests or upload anything?

No. The reference is embedded in the page script. Search and filters run entirely in your browser; nothing is transmitted to DroidXP for this feature.

Is every possible HTTP status listed here?

This page focuses on standard and commonly encountered codes. IANA may assign additional codes over time; vendor-specific codes exist beyond nginx/Cloudflare examples here. For authoritative registration data, consult the IANA HTTP Status Code Registry.

Why might my server show a different reason phrase?

Frameworks and proxies sometimes substitute or localize text. The number is what clients and caches key on; treat phrases as informative, not contractual.

What is the difference between 302, 307, and 308?

302 Found historically allowed changing POST to GET on redirect; behavior varied. 307 Temporary Redirect and 308 Permanent Redirect preserve the original method and body. Prefer 307/308 when method preservation matters.

What about 418 I’m a teapot?

It originated as an April Fools joke (RFC 2324). Some stacks return it for fun or as a placeholder. Do not rely on it for production API contracts.

When should I use 401 vs 403?

401 Unauthorized means authentication is missing or invalid (often with WWW-Authenticate). 403 Forbidden means the server understood who you are but refuses access. (Naming is confusing: “Unauthorized” really means “unauthenticated” in practice.)

Are Cloudflare and nginx codes real HTTP codes?

They are non-standard extensions used by those products between the edge and the client. Browsers may display them when the edge cannot reach your origin. Your origin may never emit them directly.

422 vs 400 for validation errors?

Many APIs use 422 Unprocessable Content when JSON is syntactically fine but business rules fail; others use 400 Bad Request for everything invalid. Pick one convention per API and document it.