HTTP Status Codes Cheat Sheet: Every Code Explained
Complete HTTP status codes reference — 1xx to 5xx. Learn what every code means, when servers send them, and how to debug common errors like 404, 403, and 500.
- Complete HTTP status codes reference — 1xx to 5xx.
- What Are HTTP Status Codes?.
- Covers 1xx — informational responses.
- Covers 2xx — success responses.
- Covers 3xx — redirection.
What Are HTTP Status Codes?
Every HTTP response includes a three-digit status code that tells the client what happened. The first digit defines the category: 1xx for informational, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors.
Status codes are part of the HTTP protocol itself — they're not a framework feature or server-specific convention. Every web server, API, CDN, and browser understands them. When you see a 404 page, your browser received an HTTP response with status code 404 and rendered its error page accordingly.
1xx — Informational Responses
1xx codes indicate the server has received the request and the client should continue or wait. These are rarely seen in everyday development.
100 Continue — the server received the request headers and the client should proceed to send the body. Used when a client sends an `Expect: 100-continue` header before uploading large payloads.
101 Switching Protocols — the server is switching to a different protocol as requested. This is the standard response when upgrading an HTTP connection to a WebSocket.
103 Early Hints — allows the server to send preliminary headers (like preload links) before the final response. This lets the browser start loading critical resources while the server is still processing the request.
2xx — Success Responses
2xx codes mean the request was received, understood, and processed successfully.
background-size animation or @property registered custom properties instead.200 OK — the standard success response. The body contains the requested resource (for GET) or the result of the action (for POST).
201 Created — a new resource was successfully created. APIs typically return this after a successful POST request, often including the new resource in the body and its URL in the `Location` header.
204 No Content — the request succeeded but there's no body to return. Common for successful DELETE requests or PUT updates where the client doesn't need the updated resource echoed back.
206 Partial Content — the server is returning only part of the resource, as requested by the client's `Range` header. Used for resumable downloads and video streaming.
3xx — Redirection
3xx codes tell the client to look elsewhere for the resource.
301 Moved Permanently — the resource has a new permanent URL. Browsers and search engines update their records. Use this when you've permanently restructured URLs.
302 Found — temporary redirect. The client should continue using the original URL for future requests. Often used during maintenance or A/B testing.
304 Not Modified — the resource hasn't changed since the client's last request (based on cache headers). The browser uses its cached copy, saving bandwidth and load time.
307 Temporary Redirect — like 302, but guarantees the HTTP method won't change. A POST request redirected with 307 stays a POST, whereas 302 might convert it to GET in some browsers.
308 Permanent Redirect — like 301, but preserves the HTTP method. Important for API endpoints that accept POST requests and need to redirect permanently.
4xx — Client Errors
4xx codes indicate the client sent a request the server can't or won't process.
400 Bad Request — the request is malformed. Missing required fields, invalid JSON syntax, or wrong content type. The server can't parse it.
401 Unauthorized — authentication is required but wasn't provided or is invalid. Despite the name, this is about authentication (who you are), not authorization (what you're allowed to do).
403 Forbidden — the server understood the request and the client is authenticated, but the client doesn't have permission. This is about authorization.
404 Not Found — the resource doesn't exist at this URL. The most well-known status code.
405 Method Not Allowed — the HTTP method isn't supported for this endpoint. A POST to a read-only resource, for example.
409 Conflict — the request conflicts with the current server state. Common when trying to create a resource that already exists or updating a resource with stale data.
429 Too Many Requests — the client has exceeded the rate limit. APIs use this with a `Retry-After` header to tell the client when to try again.
5xx — Server Errors
5xx codes mean the server failed to fulfill a valid request.
500 Internal Server Error — the catch-all server error. Something went wrong, but the server can't be more specific. Check server logs for the actual error.
502 Bad Gateway — the server (acting as a proxy or gateway) received an invalid response from an upstream server. Common when a reverse proxy can't reach the application server.
503 Service Unavailable — the server is temporarily unable to handle requests. Usually due to maintenance or overload. Should include a `Retry-After` header.
504 Gateway Timeout — the server (acting as a proxy) didn't receive a timely response from the upstream server. The request took too long to process.
Debugging Common Status Codes
Getting a 404? Check the URL for typos, verify the resource exists on the server, and check for trailing-slash mismatches. Many servers treat `/page` and `/page/` as different URLs.
Getting a 403? Verify file permissions on the server, check `.htaccess` or server configuration rules, and ensure authentication credentials are being sent correctly.
Getting a 500? Check server error logs — the 500 response itself rarely contains useful detail. Common causes are unhandled exceptions, database connection failures, and misconfigured server settings.
Getting a 502 or 504? The application server is likely down or overloaded. Check if the backend process is running, review memory and CPU usage, and verify the proxy configuration points to the correct upstream address and port.
Status Codes in API Design
Well-designed REST APIs use status codes precisely. Return 201 for created resources (not 200). Return 204 for successful deletes (not 200 with an empty body). Return 422 for validation errors when the syntax is valid but the data isn't (e.g., email format is wrong).
Avoid returning 200 for everything with an error field in the body — this makes it impossible for clients to use standard HTTP error handling. Each status code carries semantic meaning that HTTP clients, monitoring tools, and CDNs rely on.
For paginated responses, 200 is correct even when there are more pages. Use Link headers or response metadata to indicate pagination state.
SEO Impact of Status Codes
Status codes directly affect how search engines crawl and index your site. 301 redirects pass most link equity to the new URL — use them for permanent URL changes. 302 redirects tell crawlers the old URL should stay in the index.
Soft 404s — pages that return 200 but display "page not found" content — are an SEO problem. Google detects them and may flag them in Search Console, but it's better to return an actual 404 status code.
A spike in 5xx errors tells search engines your site is unreliable, which can hurt crawl frequency and rankings. Monitor your server error rate and set up alerts for sustained 5xx responses.