All 64 status codes the IANA registry has assigned, plus the 21 that nginx, Cloudflare, AWS and Laravel ship without one. Type any number and get an answer.
Related reading
Initializing in your browser…
Paste a page head and see the card each platform actually gets: the title cut at its own limit, the image measured, and what the protocol says is missing.
Build a Subresource Integrity attribute, with more than one hash if you want, and check an existing one against the file it is meant to pin.
Every fact about an IPv4 or IPv6 block, plus splitting, merging, range to CIDR, and which special-purpose range an address falls in
Your API returns a 422 and a teammate insists "that is not a real status code." You want the authority rather than another cheat sheet, and the authority is the IANA registry.
Looked up
422
Reference entry
422 Unprocessable Content 4xx Client Error The syntax is fine and the content type is understood, but the instructions inside cannot be followed. This is the code for a request that parses and still makes no sense. Formerly Unprocessable Entity (RFC 4918). Both names find it in the search box. RFC 9110 renamed this in 2022 and moved it out of WebDAV into core HTTP. Spring deprecated its own UNPROCESSABLE_ENTITY constant in favour of UNPROCESSABLE_CONTENT. [Not heuristically cacheable] [Carries content] RFC 9110, Section 15.5.21 MDN
The teammate is wrong twice over, and the second half is the interesting one. 422 is registered, so it is a real status code. It is also no longer called Unprocessable Entity: RFC 9110 renamed it Unprocessable Content in June 2022 and moved it out of WebDAV into core HTTP, and the registry carries the new name. Almost every reference on the web still prints the old one, which is why both names are searchable here and the former name is shown with the document that gave it.
The registry settles three other things a hand-maintained list usually gets wrong. 413 was renamed the same way, from Payload Too Large to Content Too Large. 418 is in the registry, but as "(Unused)" and reserved: RFC 9110 section 15.5.19 says the joke was deployed often enough that the number can never be assigned to anything real, so a list that prints it as an ordinary client error is stating a joke as protocol. And 510 carries the word OBSOLETED in the registry entry itself.
The codes that are not in the registry are here too, and marked as such. 499 is nginx, 521 is Cloudflare, 419 is Laravel, 463 is an AWS load balancer. None of them means anything to software that did not ship them, because RFC 9110 section 15 requires a client that meets an unrecognised code to treat it as the x00 of its class: to everything else, a 499 is a 400 and a 521 is a 500. Typing any number in the box gives that answer, including for the 400-odd numbers nobody has assigned.
Every status code the IANA registry has assigned, with the RFC section that defines it, plus the codes vendors ship that the registry has never assigned. Type any number and get an answer, including for the ones nobody has assigned: RFC 9110 says what a client must do with those too.
There are 64 status codes assigned in the IANA HTTP Status Code Registry: 5 informational, 10 successful, 9 redirection, 29 client error and 11 server error. That list is the authority on which codes exist and what each one is called, and it is where a hand-maintained cheat sheet drifts.
Four of those entries are commonly printed wrong. 413 is Content Too Large, not Payload Too Large: RFC 9110 renamed it in 2022. 422 is Unprocessable Content, not Unprocessable Entity, renamed at the same time and moved out of WebDAV into core HTTP, to the point that Spring has deprecated its own UNPROCESSABLE_ENTITY constant in favour of UNPROCESSABLE_CONTENT. 510 carries the word OBSOLETED inside the registry entry itself. And 418 is in the registry as "(Unused)" and reserved, which is a stronger statement than being absent: RFC 9110 section 15.5.19 says the April Fools code from RFC 2324 was deployed as a joke often enough that the number is unusable, so it is reserved and can be reassigned only if the 4xx range runs out. Both names are searchable here, and the entry says which document gave each one.
Two codes that reference lists usually drop are here for the same reason. 306 is reserved, which is why there is a gap between 305 and 307 that nothing ever explains. And 104 Upload Resumption Supported is a temporary registration rather than a permanent one, recorded as expiring on 2026-11-13, which is the kind of thing a static list carries for years after it lapses.
Beyond the registry sit 21 codes that real infrastructure emits and no standard defines: 499 and 444 from nginx, 520 to 526 and 530 from Cloudflare, 460, 463, 464, 561 and 562 from an AWS Application Load Balancer, 419 from Laravel. Each one here was read out of that vendor’s own source or documentation rather than copied from another list, and each is marked as unregistered with the vendor named. The reason that matters is a rule in RFC 9110 section 15: a client must understand the class of any status code and treat an unrecognised one as the x00 of its class. So a 499 is a 400 to anything that did not ship it, and a 521 is a 500. Typing any three digit number into the search box gives that answer, whether the number is registered, reserved, vendor specific, unassigned, or outside 100 to 599 altogether.
Two properties are attached to every code because they change behaviour and are almost never in a status code table. Heuristic cacheability: RFC 9110 section 15.1 makes exactly twelve codes cacheable with no cache headers at all, and 404 is one of them, which is why a fixed URL can keep returning 404 for some clients. And content: RFC 9110 section 6.4.1 says all 1xx, 204 and 304 responses do not include content, so a body on those is a protocol error rather than an empty string. The redirect pairs are separated the same way: 301 and 302 allow a user agent to turn a POST into a GET and 303 requires it, while 307 and 308 keep the method and the body.
The tool sends no requests and holds the whole dataset inline. The search box matches a number, a current name, a name the code used to have, a vendor, or a class written as 4xx. Each row expands to the meaning, the RFC section it comes from as a link to that section, and a link to MDN only where MDN actually has a page: it has none for 104, 305 or 306, which was checked with a request rather than assumed.
Not a standard code. nginx uses it to record that the client closed the connection before a response header could be sent, so no response was ever sent with it. Anything else reads it as 400.
400 is for a request the server cannot parse. 422 is for one that parses and whose instructions still cannot be followed. The registry now calls it Unprocessable Content.
In the registry, as (Unused), and reserved so nothing can ever be assigned to it. That is a different statement from a joke code that was never registered.
Cloudflare could not connect to the origin. The origin firewall blocking Cloudflare addresses is the usual cause, and the code says nothing to any client that is not Cloudflare.
Filter to Unregistered and see the 21 that nginx, Cloudflare, AWS and Laravel emit, with what each vendor means by it and the source it was read from.
The 4xx entries separate the ones that get confused: 400 against 422, 401 against 403, 409 against 412, and 429 with the header that says when to come back.
Twelve codes are heuristically cacheable with no cache headers at all. Each row says whether this one is.
301, 302 and 303 allow or require the method to change. 307 and 308 do not. Each redirect row says which it is.
401 means the request has not been authenticated, and the response must carry a WWW-Authenticate header saying how to authenticate. 403 means the server knows who you are and is refusing anyway, so sending credentials again will not help. The name Unauthorized on 401 is the source of the confusion: it means unauthenticated.
Use 404 when the resource is not found and you are not saying whether that is permanent. 410 says it existed and is permanently gone with no forwarding address. Both are heuristically cacheable, so both can be stored and reused by a cache with no cache headers at all.
It is in the IANA registry, and it is reserved rather than assigned. RFC 9110 section 15.5.19 explains why: RFC 2324 defined it as a joke in an April 1 document, it was deployed as a joke often enough to be unusable, and it is now reserved so that nothing real can be assigned to it unless the 4xx range runs out. So it is neither an ordinary status code nor simply absent.
Because nginx invented it. Its own source defines 499 as the code for a client that closed the connection before nginx could send a response header, which means it only ever appears in logs, never on the wire. RFC 9110 section 15 requires anything that does not recognise a status code to treat it as the x00 of its class, so to every other piece of software a 499 is a 400.
Exactly twelve: 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501. RFC 9110 section 15.1 calls them heuristically cacheable, which means a cache may store and reuse them on its own judgement. 404 being on that list surprises people regularly.
Because 301 and 302 allow it. RFC 9110 records that user agents have historically changed the method to GET when following those two, and 303 requires the change. If the method and body have to survive, use 307 or 308, which are the versions of 302 and 301 without that history.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.