Complete reference with descriptions, real-world examples, and troubleshooting guides for every common HTTP response code.
The server has received the request headers and the client should proceed to send the request body.
When it occurs: Sent when a client makes a request with an Expect: 100-continue header, typically before uploading a large body. The server signals it's willing to accept the payload.
The server is switching protocols as requested by the client via the Upgrade header.
When it occurs: During WebSocket connection upgrades. The client sends Upgrade: websocket and the server responds with 101 to confirm the protocol switch.
The request succeeded. The meaning depends on the HTTP method used.
When it occurs: GET — resource retrieved. POST — resource created or action completed. PUT — resource updated. This is the standard successful response.
The request succeeded and a new resource was created as a result.
When it occurs: After a successful POST request that creates a new record. The response typically includes a Location header pointing to the new resource.
The request succeeded but there is no content to return. The client should not navigate away from the current page.
When it occurs: After a successful DELETE request, or a PUT/PATCH where the server doesn't return the updated representation.
The server is delivering only part of the resource due to a range header sent by the client.
When it occurs: During video streaming, resumable downloads, or any time the client requests a byte range with the Range header. The response includes a Content-Range header.
The resource has been permanently moved to a new URL. All future requests should use the new URL.
When it occurs: When a page URL changes (e.g., site restructuring). Search engines transfer link equity to the new URL. Browsers cache this redirect.
The resource is temporarily located at a different URL. Future requests should still use the original URL.
When it occurs: Temporary maintenance redirects, A/B testing, or login redirects. Search engines continue to index the original URL. Note: many clients change the method to GET on 302, which is technically incorrect — use 307 for preserving the method.
The resource has not been modified since the last request. The client should use its cached copy.
When it occurs: When the client sends an If-None-Match (ETag) or If-Modified-Since header and the server determines nothing changed. Saves bandwidth — no body is sent.
The resource is temporarily at a different URL. The request method and body must not change when redirecting.
When it occurs: Similar to 302 but guarantees the HTTP method (POST, PUT, etc.) is preserved during the redirect. Used when you need a true temporary redirect without method conversion.
The resource has permanently moved. The request method and body must not change when redirecting.
When it occurs: Like 301 but guarantees the HTTP method is preserved. Use when permanently redirecting a POST endpoint to a new URL and you need clients to continue sending POST requests to the new location.
The server cannot process the request due to something perceived to be a client error (e.g., malformed request syntax).
When it occurs: Invalid JSON body, missing required fields, malformed URL parameters, or invalid request headers.
Authentication is required and has either not been provided or has failed.
When it occurs: Accessing a protected API without an Authorization header, using an expired JWT token, or providing invalid credentials.
Authorization header (e.g., Bearer token), refresh expired tokens, verify credentials, or log in to obtain a new session.The server understood the request but refuses to authorize it. The client lacks permission to access the resource.
When it occurs: Trying to access admin pages without admin privileges, accessing another user's private data, or when IP-based access controls block the request.
The requested resource could not be found on the server.
When it occurs: Typo in the URL, the page was deleted, the resource ID doesn't exist in the database, or the route is not configured on the server.
The request method is not supported for the requested resource.
When it occurs: Sending a POST to a read-only endpoint, or a DELETE to a resource that only supports GET. The response should include an Allow header listing valid methods.
Allow response header for supported methods, update your request to use the correct HTTP method, or add the missing method handler on the server.The server timed out waiting for the client to send the complete request.
When it occurs: The client opened a connection but took too long to send headers or body. Common on slow or unstable network connections, or when uploading large files.
The user has sent too many requests in a given amount of time (rate limiting).
When it occurs: Exceeding API rate limits, running aggressive scrapers, or sending too many login attempts. The response may include Retry-After header.
Retry-After header, implement exponential backoff in your client, reduce request frequency, or contact the API provider to increase your rate limit.The server encountered an unexpected condition that prevented it from fulfilling the request.
When it occurs: Unhandled exceptions in application code, database connection failures, configuration errors, or runtime crashes. This is the generic catch-all server error.
The server, acting as a gateway or proxy, received an invalid response from the upstream server.
When it occurs: Nginx/Apache can't reach the backend application, the upstream server crashed, or there's a network issue between the proxy and origin server.
The server is not ready to handle the request. Common causes are maintenance or overload.
When it occurs: Server is under heavy load, scheduled maintenance, or the application is starting up. Often temporary — the Retry-After header may indicate when to try again.
Retry-After), scale server resources, check for traffic spikes, review deployment status, and ensure health check endpoints are properly configured.The server, acting as a gateway, did not receive a timely response from the upstream server.
When it occurs: The upstream server is too slow to respond, database queries are taking too long, or there's a network timeout between the proxy and backend.
Filter by code number, name, or keyword in real time. Find any status code in under a second.
Visual category system — green for success, blue for redirects, yellow for client errors, red for server errors.
Actionable troubleshooting steps for every error code. Know exactly what to do when something breaks.
Fully responsive design that works on phones, tablets, and desktops. Book it for quick lookups on the go.
curl -I https://example.com in your terminal, open browser DevTools (F12 → Network tab), or use online tools like HTTPStatus.io. For bulk checking, tools like Screaming Frog can crawl entire sites and report all status codes.Get notified when we add new HTTP references and web development guides.