HTTP Status Codes Explained: A Developer's Reference

What Are HTTP Status Codes?

Every HTTP response includes a three-digit status code that tells the client what happened to the request. The first digit indicates the category:

Class	Range	Meaning
Informational	1xx	Request received, continuing process
Success	2xx	Request successfully received, understood, and accepted
Redirection	3xx	Further action needed to complete the request
Client Error	4xx	Request contains bad syntax or cannot be fulfilled
Server Error	5xx	Server failed to fulfil an apparently valid request

Status codes are standardised in RFC 9110 and have been stable since the early web. Understanding them is fundamental for debugging APIs, configuring servers, and building robust web applications.

1xx — Informational

100 Continue

The server has received the request headers and the client should proceed to send the request body. Used with Expect: 100-continue to check if the server will accept a large upload before sending it.

101 Switching Protocols

The server agrees to switch protocols as requested by the client (e.g., upgrading from HTTP/1.1 to WebSocket). You'll see this when establishing a WebSocket connection.

103 Early Hints

The server is sending preliminary headers (typically Link: rel=preload) before the final response, allowing the browser to preload resources.

2xx — Success

200 OK

The request succeeded. The response body contains the requested data. The workhorse of the web.

201 Created

The request succeeded and a new resource was created. Always returned from a successful POST to a REST API endpoint that creates a resource. The Location header should point to the new resource URL.

202 Accepted

The request has been accepted for processing, but processing is not complete. Used for asynchronous operations — the client needs to poll or use a webhook to get the final result.

204 No Content

The request succeeded but there is no response body. Common for DELETE requests or PUT updates where returning the updated resource is unnecessary.

206 Partial Content

The server is delivering part of a resource in response to a Range request. Used by media streaming (video seeking), download managers with resume support, and large file chunk downloads.

3xx — Redirection

301 Moved Permanently

The resource has permanently moved to a new URL (provided in the Location header). Browsers cache this redirect. Search engines transfer link equity to the new URL. Use this for permanent SEO-friendly URL changes.

302 Found (Temporary Redirect)

The resource is temporarily at a different URL. Browsers follow the redirect but do not cache it. Search engines keep the original URL indexed.

303 See Other

The response to the request can be found at another URI using GET. Used after a POST to redirect to a confirmation page (the Post/Redirect/Get pattern) — prevents duplicate form submissions on back navigation.

304 Not Modified

The client's cached version of the resource is still current. No body is sent — the client should use its cached copy. Triggered by conditional requests using If-Modified-Since or If-None-Match headers.

307 Temporary Redirect

Like 302, but the HTTP method must not change (a POST stays a POST). 302 historically allowed method changes; 307 is the strict modern version.

308 Permanent Redirect

Like 301, but the HTTP method must not change. Use 308 for permanent redirects where preserving the request method matters (e.g., redirecting a POST endpoint permanently).

4xx — Client Errors

400 Bad Request

The server cannot process the request due to malformed syntax or invalid parameters. Common causes: missing required fields, invalid JSON, incorrect data types.

401 Unauthorized

Authentication is required and has not been provided, or the credentials provided are invalid. Despite the name, it really means "unauthenticated". The WWW-Authenticate header should indicate the authentication scheme expected.

403 Forbidden

The server understood the request but refuses to authorise it. The client is authenticated but does not have permission to access the resource. Unlike 401, re-authenticating won't help.

404 Not Found

The server cannot find the requested resource. The most famous HTTP status code. Can mean the URL never existed, or the resource has been deleted. For security, APIs sometimes return 404 instead of 403 to avoid disclosing that a resource exists.

405 Method Not Allowed

The HTTP method used is not supported for this endpoint. For example, sending a DELETE to an endpoint that only accepts GET and POST. The Allow header should list the permitted methods.

409 Conflict

The request conflicts with the current state of the server. Used when creating a resource that already exists, or when concurrent modifications conflict (optimistic locking scenarios).

410 Gone

The resource existed but has been permanently deleted. Unlike 404, which is ambiguous, 410 tells clients (and search engine bots) they should remove the URL from their records.

422 Unprocessable Entity

The server understands the content type and the request is syntactically correct, but the semantic content is invalid (e.g., a start_date is after an end_date). Common in REST APIs for validation errors.

429 Too Many Requests

Rate limiting in action. The client has sent too many requests in a given time period. The Retry-After header should indicate when to try again.

5xx — Server Errors

500 Internal Server Error

A generic catch-all for unexpected server failures. The server encountered an error it doesn't know how to handle. Check server logs for the actual cause — this is almost always a bug.

502 Bad Gateway

The server, acting as a gateway or proxy, received an invalid response from an upstream server. Common when Nginx or a load balancer can't reach the application server behind it.

503 Service Unavailable

The server is not ready to handle the request — usually due to being overloaded or down for maintenance. Should include a Retry-After header. Often returned by a load balancer when no healthy backends are available.

504 Gateway Timeout

The server, acting as a gateway, did not receive a timely response from an upstream server. Indicates the upstream took too long — check for slow database queries, unresponsive external APIs, or misconfigured timeouts.

REST API Best Practices

When building APIs, using the right status codes communicates intent clearly:

Action	Success	Client Error
GET resource	200	404 (not found), 400 (bad params)
POST create	201	400 (invalid), 409 (conflict)
PUT update	200 or 204	404 (not found), 422 (invalid)
DELETE	204	404 (not found), 403 (forbidden)
Authentication fail	—	401
Permission denied	—	403

Debugging with Status Codes

When an API or page is not behaving as expected:

1. Open browser DevTools → Network tab — check the status code for every request
2. 4xx errors — fix the request (wrong URL, missing auth header, invalid body)
3. 5xx errors — check server logs; the problem is on the server side
4. Unexpected 301/302 — check for redirect loops; verify HTTPS redirects are working
5. 304 instead of 200 — your caching logic is working, but if data looks stale, check Cache-Control and ETag headers

Use the HTTP Status Code Reference

The HTTP Status Codes tool on DevGizmo provides a searchable, filterable reference of all standard HTTP status codes with explanations. Look up any code instantly during debugging or API development.