HTTP Status Code Lookup

Search and browse every HTTP status code with QA-focused guidance, common mistakes, and test-assertion tips.

Runs 100% client-side
On this page4 sections
Group:

29 status codes

HOW TO USE

  1. 01Search by code (e.g. 401) or keyword (e.g. 'redirect') to find a status code.
  2. 02Read the meaning, the family (2xx/3xx/4xx/5xx), and the QA checks listed for that code.
  3. 03Use the QA checks to write targeted assertions for the response you're testing.

Try it

Search 201 to confirm the correct code for resource creation

WHEN TO USE

Use this reference whenever you need to verify the semantically correct status code for an API response, understand an unfamiliar code returned in a test, or write targeted assertions. It is especially useful during API code review (confirming 201 vs 200 on resource creation), incident diagnosis (decoding 5xx families), and when building automated checks that assert on more than just 200 OK.

WHAT BUGS THIS FINDS

  • Wrong success code class

    API returns 200 for resource creation instead of 201 — passes basic tests but breaks clients expecting Location headers.

  • Swapped 401/403

    Server returns 403 when credentials are missing (should be 401) — misleads clients about whether to retry with auth.

  • 500 masking 4xx

    Validation errors returned as 500 Internal Server Error instead of 400/422 — hides the root cause and bypasses client error handling.

  • 204 with a body

    No-Content response includes a response body — causes parsing failures in strict clients.

QA USE CASES

01

Assert semantically correct codes

Verify a POST that creates a resource returns 201, not 200 — both succeed but only one is semantically correct.

02

Diagnose 4xx vs 5xx failures

Distinguish client-side errors (your test data or auth) from server-side errors (bug) to triage failures faster.

03

Test auth flows

Confirm 401 (missing/invalid credentials) is distinct from 403 (valid credentials, insufficient permissions).

04

Validate redirect handling

Ensure 301/308 permanent redirects are followed correctly and 307/302 temporary ones preserve the request method.

05

Check idempotency

Confirm that repeated PUT/DELETE operations return 200/204 (not 201) on subsequent calls.