Reference Tools
Quick reference guides for developers. Look up codes, standards, and specifications.
A quick, dependable reference beats a browser tab full of search results. This category keeps the lookups developers do constantly - starting with HTTP status codes - in one place.
1 tool availableRead the class first, then read the body
HTTP status codes fall into five classes, and RFC 9110 defines each one in a single sentence worth memorising. 1xx is "an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response"; 2xx means "the client's request was successfully received, understood, and accepted"; 3xx says "further action needs to be taken by the user agent in order to fulfill the request"; 4xx means "the client seems to have erred"; and 5xx means "the server is aware that it has erred or is incapable of performing the requested method".
| Class | What it means | What a test asserts next | RFC 9110 |
|---|---|---|---|
| 1xx Informational | an interim response; a final response still follows | assert the interim-then-final sequence; a client waiting on a body has not failed yet | section 15.2 |
| 2xx Successful | request received, understood and accepted | assert the representation - the code alone passes broken payloads | section 15.3 |
| 3xx Redirection | the user agent must take further action | follow the Location header and re-check the method; a redirected POST can arrive as a GET | section 15.4 |
| 4xx Client Error | the client seems to have erred | fix the request first, and read the explanation the server should be sending | section 15.5 |
| 5xx Server Error | the server knows it erred or cannot perform the method | file a defect with the request evidence; retrying is a policy decision, not a default | section 15.6 |
The reason phrase is not data
The human-readable phrase that ships beside a status code is decoration. RFC 9110 section 15.1 states that the reason phrases "are only recommendations -- they can be replaced by local equivalents or left out altogether without affecting the protocol". A test that asserts "Not Found" rather than 404 is a false-negative generator: it fails the day an edge proxy localises the phrase, and it passes the day a bug returns 404 with the wrong body. Assert the number, then assert the machine-readable fields of the representation.
In API work the class is the first triage split, not the verdict. A 4xx caused by your own test data looks identical to a 4xx caused by a field-level bug, and a 5xx is not automatically a flake. Compare the error body against the contract, then reproduce with the smallest request that still fails - the API testing guide walks through that loop, and the status code reference maps each code to its section of the specification. When the code looks wrong at the edge rather than in the application, the debugging guide covers the DNS, TLS and header layers underneath it.
Source: RFC 9110: HTTP Semantics - section 15 (status code classes; section 15.1 on reason phrases).