About this tool
Pick the situation you are answering and the tool names the status code that fits, the headers that must travel with it, and a response head you can paste straight into a test. Situations run from created, updated, deleted and accepted through validation failure, permissions, conflict, preconditions and rate limiting, and the places where carrying a body changes the code are handled too: a successful update is 200 with a body and 204 without one.
When a situation has more than one candidate, the alternatives are listed with the condition under which each applies. The meanings follow RFC 9110 as of October 2026, and codes that come from RFC 6585, which defined additional status codes, are marked separately. Where the specification is silent, the text says so: using 422 for validation failures and answering 404 instead of 403 to hide existence are both convention.
Missing required headers are reported as errors. A 401 needs a header stating how to authenticate, a 405 needs the list of accepted methods, and creation and moves need Location. This tool is not a dictionary you look a code number up in, and it does not help choose which method to use.
Frequently asked questions
No. A 204 is defined to end at the blank line after its headers, so appended content can be misread by the recipient as the start of the next response. Use 200 when there is something to return.
The specification leaves this open, so it is convention. It defines 422 only as content that cannot be processed, not as a validation-specific code. Using 400 for a broken shape and 422 for a readable shape whose values break the rules is common, but what matters is settling on one within the team.
It does not work as a dictionary you look code numbers up in, and it does not choose methods. It goes from a situation to a code and builds the response head.