Look up every HTTP status code from 100 to 511. Searchable reference with plain-English explanations, category filters, and copy-to-clipboard.
HTTP status codes are three digit numbers returned by a server in response to a client request. The first digit defines the category: 1xx for informational, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors. Every web developer and API consumer encounters these codes daily, and knowing what they mean saves debugging time.
An HTTP status code is a three digit number that a server sends back to a client (browser, mobile app, API client) after receiving a request. It tells the client what happened: did the request succeed, fail, or require more information? Status codes are part of the HTTP protocol specification (RFC 9110) and are standardized across all web servers and APIs. When you open a website, your browser receives a status code (usually 200 OK) along with the page content. When you make an API call and get a 404, it means the resource you requested does not exist. Understanding status codes is fundamental to debugging web applications, building APIs, and working with any HTTP-based service.
Interim responses. The server has received the request and the client should continue or wait. You rarely see these directly. The most practical one is 101 Switching Protocols, which is how HTTP upgrades to WebSocket.
The request was received, understood, and accepted. 200 OK is the standard success response. 201 Created is the correct response for a POST that creates a new resource. 204 No Content is what you return for a successful DELETE when there is nothing to send back. Using the right 2xx code makes APIs self documenting.
Further action is needed to complete the request, usually following a Location header. 301 and 308 are permanent redirects (search engines transfer ranking). 302 and 307 are temporary (search engines keep the original URL). The difference between the paired codes: 307/308 guarantee method preservation, while 301/302 allow browsers to change POST to GET.
The request contains bad syntax or cannot be fulfilled. These are the caller’s fault. 400 Bad Request covers malformed input. 401 is for missing or invalid credentials. 403 is for valid credentials that lack permission. 404 is the universal “not found.” 422 is for valid syntax that fails business validation (common in REST APIs). 429 is rate limiting.
The server failed to fulfill a valid request. These are the server’s fault. 500 is the general purpose error. 502 and 504 point to proxy/gateway issues (the app server behind the proxy crashed or timed out). 503 means the server is temporarily overloaded or down for maintenance.
When debugging API integrations, start by checking whether the status code is a 4xx (fix your request) or a 5xx (check the server). Need to inspect a JWT that came back with a 401? Try the JWT Decoder. Building URLs for API requests? The URL Encoder handles percent encoding correctly. Compare two API responses to find what changed with the Diff Checker. Format malformed JSON from error responses with the JSON Formatter. Test patterns in error messages with the Regex Tester. Not sure which code to pick? The Which Status Code Should I Use? decision guide walks through common scenarios.
Nothing you paste leaves this tab. Every tool runs entirely in your browser — no upload, no server, no account.