What is the difference between 401 and 403?

401 means the server does not know who you are — credentials are missing, expired or malformed — and it must send a WWW-Authenticate header telling you how to authenticate. Retrying with a valid token fixes it. 403 means the server knows exactly who you are and is refusing anyway, so retrying with the same identity will never work. The names are misleading: 401 should have been "Unauthenticated".

When should an API return 422 instead of 400?

400 is for a request the server cannot parse or process at the protocol level — malformed JSON, a missing required header, a bad query parameter. 422 Unprocessable Content is for a request that parsed perfectly but fails your business rules: valid JSON where the email field is not an email, or a date range that ends before it starts. The distinction tells a client whether to fix its syntax or fix its data, which is why most REST APIs use both.

Which redirect should I use, 301, 302, 307 or 308?

Two questions decide it. Is the move permanent? Permanent means 301 or 308, temporary means 302 or 307. Must the HTTP method survive the redirect? 307 and 308 guarantee a POST stays a POST; 301 and 302 historically allowed clients to downgrade it to GET, and many still do. So: 308 for a permanently moved POST endpoint, 301 for a permanently moved page, 307 for a temporary redirect that must preserve the method, 302 otherwise. Note that browsers cache 301 aggressively, which makes it painful to undo.

Is 404 or 410 better for a page I deleted?

410 Gone, if you are certain it is not coming back. Both tell a client the resource is not there, but 410 says the absence is deliberate and permanent, and search engines act on it faster than on a 404 — which they treat as possibly temporary and keep re-checking. Use 404 when the URL was simply never valid, or when you want to conceal whether something exists from an unauthorised caller.

Is my data private when I use this tool?

Yes. This tool runs entirely in your browser using client-side JavaScript — nothing you type is transmitted to, logged by, or stored on any server. You can safely process confidential text, tokens, or code.

HTTP Status Code Lookup — What Every Code Means

Look up any HTTP status code and get what it means, when to use it, and which RFC defines it. Searchable reference covering 1xx through 5xx. Free and instant.

🔒 100% Client-Side Processing

Your data is processed entirely in your browser and never transmitted to any server.

Example

Input

422

Output

422 Unprocessable Content — Client error (RFC 9110)

Syntactically valid but semantically wrong: well-formed JSON that fails validation. Distinct from 400, which means the server could not parse the request at all.

32 of 32 codes

100ContinueInformationalRFC 9110
The client should keep going with the request body. Sent in reply to an Expect: 100-continue header, so a large upload is not wasted if the server would reject the headers.
101Switching ProtocolsInformationalRFC 9110
The server agrees to change protocol on this connection. This is the handshake response that upgrades HTTP to a WebSocket.
103Early HintsInformationalRFC 8297
Preliminary headers sent before the real response, so the browser can start preloading assets while the server is still working.
200OKSuccessRFC 9110
The request succeeded. For GET the body is the resource; for POST it is the result of the action.
201CreatedSuccessRFC 9110
A new resource now exists as a result of this request. Should carry a Location header pointing at it.
202AcceptedSuccessRFC 9110
The request is valid and queued, but not finished. Use for asynchronous jobs where the outcome is not known yet.
204No ContentSuccessRFC 9110
Succeeded, and there is deliberately no body. Common for DELETE and for PUT updates that return nothing.
206Partial ContentSuccessRFC 9110
Returning only the byte range the client asked for via the Range header. Underpins resumable downloads and video seeking.
301Moved PermanentlyRedirectionRFC 9110
The resource has a new URL for good. Search engines transfer ranking signals to the target; browsers cache it aggressively, so it is hard to undo.
302FoundRedirectionRFC 9110
A temporary redirect. The original URL stays canonical, so use this when the move is not permanent.
304Not ModifiedRedirectionRFC 9110
The cached copy is still fresh, so no body is sent. Triggered by If-None-Match or If-Modified-Since.
307Temporary RedirectRedirectionRFC 9110
Like 302 but the method must not change. A POST stays a POST, which 302 historically did not guarantee.
308Permanent RedirectRedirectionRFC 7538
Like 301 but preserves the method and body. The right choice for permanently moving a POST endpoint.
400Bad RequestClient errorRFC 9110
The server cannot parse or accept the request as sent — malformed JSON, a missing required field, an invalid parameter.
401UnauthorizedClient errorRFC 9110
Authentication is missing or invalid. Misnamed: it means unauthenticated. Must include a WWW-Authenticate header.
403ForbiddenClient errorRFC 9110
The server knows who you are and still refuses. Unlike 401, retrying with credentials will not help.
404Not FoundClient errorRFC 9110
No resource at this URL. Also used deliberately to hide the existence of something from an unauthorised caller.
405Method Not AllowedClient errorRFC 9110
The URL exists but not for this verb — POST to a read-only endpoint. Must list the permitted ones in an Allow header.
409ConflictClient errorRFC 9110
The request clashes with current state: a duplicate unique key, or an edit against a version someone else already changed.
410GoneClient errorRFC 9110
Deliberately removed and not coming back. Stronger than 404, and search engines drop the URL faster.
415Unsupported Media TypeClient errorRFC 9110
The Content-Type is not one the endpoint accepts — usually sending form data where JSON was expected, or omitting the header entirely.
418I'm a TeapotClient errorRFC 2324 / 7168
An April Fools joke from 1998 that was never removed. Some APIs use it as a deliberate no-op or honeypot response.
422Unprocessable ContentClient errorRFC 9110
Syntactically valid but semantically wrong — well-formed JSON that fails validation. Many APIs prefer this over 400 for validation errors.
428Precondition RequiredClient errorRFC 6585
The server requires a conditional request, forcing clients to send If-Match so they cannot blindly overwrite a newer version.
429Too Many RequestsClient errorRFC 6585
Rate limited. Should include Retry-After telling you how long to wait; back off rather than retrying immediately.
431Request Header Fields Too LargeClient errorRFC 6585
The headers exceed the server limit. Usually an oversized cookie or a bloated JWT in the Authorization header.
500Internal Server ErrorServer errorRFC 9110
An unhandled failure on the server. Generic by design: the client can do nothing except retry or report it.
501Not ImplementedServer errorRFC 9110
The server does not support the method at all. Unlike 405 this is about the server, not about this specific URL.
502Bad GatewayServer errorRFC 9110
A proxy or load balancer got an invalid reply from upstream. The edge is healthy; something behind it is not.
503Service UnavailableServer errorRFC 9110
Temporarily unable to handle the request — overload or maintenance. Should send Retry-After.
504Gateway TimeoutServer errorRFC 9110
A proxy waited for upstream and gave up. Distinguishes a slow backend from a broken one, which 502 does not.
511Network Authentication RequiredServer errorRFC 6585
A captive portal is intercepting you — hotel or airport wifi demanding sign-in before it will pass traffic.

Common Use Cases

Deciding what your endpoint should return

Pick between 400 and 422, or between 401 and 403, using what each code actually signals to a client rather than guessing.

Debugging a failing integration

Translate the code a third-party API returned into what it means about your request, and whether retrying could ever help.

Choosing the right redirect

Work out whether a move needs 301, 302, 307 or 308 — the answer depends on permanence and whether the HTTP method must survive.

Writing API documentation

Describe each error your endpoint can return using the code's real meaning and defining RFC, instead of inventing your own semantics.

Frequently Asked Questions

What is the difference between 401 and 403?: 401 means the server does not know who you are — credentials are missing, expired or malformed — and it must send a WWW-Authenticate header telling you how to authenticate. Retrying with a valid token fixes it. 403 means the server knows exactly who you are and is refusing anyway, so retrying with the same identity will never work. The names are misleading: 401 should have been "Unauthenticated".
When should an API return 422 instead of 400?: 400 is for a request the server cannot parse or process at the protocol level — malformed JSON, a missing required header, a bad query parameter. 422 Unprocessable Content is for a request that parsed perfectly but fails your business rules: valid JSON where the email field is not an email, or a date range that ends before it starts. The distinction tells a client whether to fix its syntax or fix its data, which is why most REST APIs use both.
Which redirect should I use, 301, 302, 307 or 308?: Two questions decide it. Is the move permanent? Permanent means 301 or 308, temporary means 302 or 307. Must the HTTP method survive the redirect? 307 and 308 guarantee a POST stays a POST; 301 and 302 historically allowed clients to downgrade it to GET, and many still do. So: 308 for a permanently moved POST endpoint, 301 for a permanently moved page, 307 for a temporary redirect that must preserve the method, 302 otherwise. Note that browsers cache 301 aggressively, which makes it painful to undo.
Is 404 or 410 better for a page I deleted?: 410 Gone, if you are certain it is not coming back. Both tell a client the resource is not there, but 410 says the absence is deliberate and permanent, and search engines act on it faster than on a 404 — which they treat as possibly temporary and keep re-checking. Use 404 when the URL was simply never valid, or when you want to conceal whether something exists from an unauthorised caller.
Is my data private when I use this tool?: Yes. This tool runs entirely in your browser using client-side JavaScript — nothing you type is transmitted to, logged by, or stored on any server. You can safely process confidential text, tokens, or code.