HTTP Status Code Explorer

401 Unauthorized means you are not authenticated — you need to provide credentials (login, API key, JWT). 403 Forbidden means you are authenticated but do not have permission — the server knows who you are but refuses your request. In practice: 401 means log in, 403 means your role lacks the required permissions.

Use 400 Bad Request for syntactically malformed requests (invalid JSON, wrong content-type, missing required top-level parameter). Use 422 Unprocessable Entity for semantically invalid requests where the structure is valid but the values fail business rules — wrong email format, date in the past, value out of allowed range. Many APIs use 400 for both, but 422 is more precise for validation errors.

Both are permanent redirects, but 308 Permanent Redirect guarantees the HTTP method is preserved. With 301, browsers may change POST requests to GET on redirect (and many do). With 308, POST stays POST. Same relationship exists for temporary redirects: 302 may change POST to GET, 307 does not.

Use 200 OK if you return a response body (e.g., the deleted resource or a confirmation message). Use 204 No Content if you return nothing. Both are valid — 204 is slightly more semantic but 200 is more common in REST APIs. Never return 200 with an empty body when you could return 204.

Always include a Retry-After header with the number of seconds until the rate limit resets. Also include X-RateLimit-Limit (total requests allowed), X-RateLimit-Remaining (requests left in window), and X-RateLimit-Reset (Unix timestamp when window resets). Clients should exponential backoff on 429 — retry after Retry-After seconds, doubling on successive failures.

Cacheable by default (no cache headers needed): 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501. Not cacheable by default: 302, 303, 307, 308 (unless Cache-Control is explicitly set). Always cacheable: 200 with Cache-Control or Expires. Override caching with Cache-Control: no-store for sensitive responses.