Not the RFC prose — what each code actually means when your request comes back wrong, and what to check next. Every page includes the practical debug move.
Interim responses: the request was received and the process continues.
Interim response: send the request body, the headers were acceptable.
The server agrees to switch protocols, e.g. HTTP to WebSocket.
WebDAV: the server accepted the request but has not completed it yet.
Preload hints sent before the final response.
The request was received, understood and accepted.
The request succeeded; the response carries the result.
A new resource was created; Location usually points to it.
Accepted for asynchronous processing; the result comes later.
Success, but the payload was modified by a transforming proxy.
Success with intentionally empty body.
Success; the client should reset the view or form.
The server returned only the requested byte range.
WebDAV: multiple status values for multiple resources in one XML body.
WebDAV: members already listed earlier in this Multi-Status response.
Delta encoding: the response is a diff against a previous version.
Further action is needed, usually following a Location header.
Several representations exist; pick one.
The resource lives at a new URL forever; update your links.
Temporary redirect; most clients switch the method to GET.
Redirect that explicitly tells the client to GET another URL.
Your cached copy is still valid; no body is returned.
Temporary redirect that preserves the method and body.
Permanent redirect that preserves the method and body.
The request is at fault: syntax, auth, permissions or the resource itself.
The server could not parse or accept the request as sent.
Authentication is missing or invalid; the name is misleading.
Reserved for payment; used in practice for quota and billing walls.
Authenticated (or known), but not allowed to do this.
No representation exists for this URL — or the API hides that it does.
The URL exists, but not for this HTTP method.
The server cannot produce a representation matching your Accept headers.
A proxy between you and the origin wants credentials.
The server gave up waiting for your request to arrive.
The request clashes with the current state of the resource.
It existed, it was removed on purpose, it is not coming back.
The server insists on a Content-Length header.
An If-* conditional header did not hold.
The request body exceeds what the server accepts.
The URL itself exceeds server limits.
The server rejects the Content-Type of your body.
The requested byte range is outside the resource.
The server cannot meet the Expect header.
An April Fools RFC classic: the teapot refuses to brew coffee.
This server is not the right one for that URL/authority.
Syntax is fine; the data is semantically invalid.
WebDAV: the resource is locked.
The server refuses to process a possibly-replayed early request.
Switch protocols (see the Upgrade header) and try again.
The server demands conditional headers to prevent lost updates.
You hit a rate limit; slow down and honor Retry-After.
Headers (often cookies) exceed server limits.
Blocked due to legal demands (the Fahrenheit 451 code).
The server failed to fulfill an apparently valid request.
The server crashed or hit an unhandled error while processing.
The server does not support this method/functionality at all.
A proxy got an invalid response from the upstream server.
Temporarily down: overload, maintenance or no healthy backends.
The proxy gave up waiting for the upstream to answer.
The server refuses the HTTP version of the request.
Server misconfiguration in content negotiation.
WebDAV: the server has no space to complete the request.
WebDAV: infinite loop while processing the request.
The request lacks an extension the server requires.
A captive portal wants you to log in to the network.
ReqPad shows status, timing and headers for every request, with searchable history. REST, GraphQL, gRPC, MQTT, WebSocket & Socket.IO.