CodeKivo LogoCodeKivo

HTTP Status Codes

Complete reference for all HTTP status codes from 100 to 599. Search by number or keyword, inspect RFC definitions, common causes, developer fixes, and HTTP response examples.

65 / 65 codes
Filters:
404

Not Found

Client ErrorCacheable

The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

RFC:RFC 9110 §15.5.5
•
Cacheable:Yes
•
Link:

Description

The origin server did not find a current representation for the target resource.

Common Causes

  • Typo in URL or wrong route path (e.g. /api/user instead of /api/users).
  • Entity deleted from database or never existed.
  • Moved resource without a 301/302 redirect in place.
  • Server intentionally hiding existence of sensitive resource from unauthorized users.

Resolution

  • Double check URL path spelling and routing table.
  • If permanently removed, return 410 Gone for cleaner SEO de-indexing.
  • If moved, configure a 301 Moved Permanently redirect.

Response Example

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "Not Found",
  "message": "Resource '/api/v1/orders/987123' does not exist"
}
Related:

How to Use the HTTP Status Codes Reference

  • Use the search input to filter status codes by number, keyword, or phrase.
  • Select a category tab (1xx, 2xx, 3xx, 4xx, 5xx) to view codes within that class.
  • Use quick filters to display popular codes, cacheable responses, or error codes.
  • Select any status code to view its definition, causes, resolution steps, and response headers.
  • Use the copy actions to copy code numbers, response examples, or shareable anchor links.

HTTP Status Code Classes at a Glance

ClassCategoryDefinition & Core PurposeTypical Client ActionKey Examples
1xxInformationalInterim response indicating request received and processing is underway.Continue sending headers/payload or switch protocol.100, 101, 103
2xxSuccessThe action requested by the client was received, understood, and accepted.Process response payload or confirm action completion.200, 201, 204, 206
3xxRedirectionFurther action needs to be taken by user agent to complete the request.Follow "Location" header URI or load resource from cache.301, 302, 304, 307, 308
4xxClient ErrorRequest contains syntax error, unauthorized access, or unfulfillable terms.Fix client payload, provide auth token, or adjust rate limit.400, 401, 403, 404, 422, 429
5xxServer ErrorThe server is aware that it has erred or is incapable of performing the request.Retry with exponential backoff or alert backend operations.500, 502, 503, 504

Critical HTTP Status Code Comparisons

401 Unauthorized vs 403 Forbidden

401 Unauthorized: Authentication failure. The request lacks valid credentials (missing or expired Bearer token, invalid API key). Re-authenticating with valid credentials resolves the error.

403 Forbidden: Authorization failure. The identity is verified, but the client lacks permission (insufficient RBAC role, restricted IP, or tenant restriction) to access the resource.

301 / 302 vs 307 / 308 (Method Preservation)

301 / 302 (Historical): Redirects where user agents historically permitted changing the request method from POST to GET.

307 / 308 (RFC 9110): Method-preserving redirects. 307 (Temporary) and 308 (Permanent) explicitly require clients to resend the exact same HTTP method (e.g. POST remains POST) with the original body.

500 vs 502 vs 503 vs 504 (Server Diagnostics)

500 Internal Server Error: Application crash inside your code (unhandled exception, null pointer, DB connection lost).

502 Bad Gateway: Reverse proxy (Nginx/Cloudflare) reached upstream backend, but backend crashed or refused connection.

503 Service Unavailable: Temporary server maintenance or overload; search engines pause without penalty.

504 Gateway Timeout: Upstream backend took longer than proxy read timeout (e.g. slow database query).

400 Bad Request vs 422 Unprocessable Content

400 Bad Request: Syntax error in request. Malformed JSON syntax (trailing comma, unquoted key), broken query string, or invalid request headers.

422 Unprocessable Content: Syntax is 100% valid JSON, but business logic or schema validation fails (invalid email format, age < 0, date in the past).

REST API Status Code Design Matrix

HTTP VerbCRUD SemanticsIdempotent?Safe?Standard Success StatusStandard Error Statuses
GETRead / QueryYesYes200 OK, 206 Partial404, 401, 403, 304
POSTCreate / ActionNoNo201 Created, 202 Accepted400, 422, 409, 415
PUTReplace / UpsertYesNo200 OK, 204 No Content400, 404, 412, 428
PATCHPartial UpdateNoNo200 OK, 204 No Content400, 404, 422, 409
DELETEDelete / RemoveYesNo204 No Content, 202 Accepted404, 401, 403
HEADHeaders OnlyYesYes200 OK (no body)404, 304
OPTIONSCORS / CapabilitiesYesYes204 No Content, 200 OK405 Method Not Allowed

Frequently Asked Questions

What are HTTP status codes and what do the 5 classes represent?

HTTP status codes are standardized 3-digit numeric responses issued by a server in response to a client request (RFC 9110). The first digit specifies one of 5 distinct classes: 1xx Informational (request received, continuing process), 2xx Success (action successfully received, understood, and accepted), 3xx Redirection (further action needed to complete request), 4xx Client Error (request contains bad syntax or cannot be fulfilled), and 5xx Server Error (server failed to fulfill an apparently valid request).

What is the key difference between 401 Unauthorized and 403 Forbidden?

The difference lies in identity versus permission. 401 Unauthorized indicates that the client lacks valid authentication credentials (e.g. missing or expired JWT, wrong API key); re-authenticating with valid credentials will solve the issue. In contrast, 403 Forbidden means the server recognizes who you are, but you do not possess sufficient permissions (e.g. an authenticated regular member attempting an admin-only route); re-authenticating as the same user will still yield 403.

How do 301, 302, 307, and 308 redirects differ for SEO and HTTP methods?

301 Moved Permanently and 308 Permanent Redirect are permanent redirects that pass full SEO link equity (PageRank). 302 Found and 307 Temporary Redirect are temporary and do not transfer link equity. Regarding HTTP methods: historical user agents rewrote POST requests to GET upon receiving 301 or 302. To prevent method mutation, RFC 9110 introduced 307 (temporary) and 308 (permanent), which strictly forbid clients from altering the HTTP method (e.g. POST remains POST).

What is the technical difference between 500, 502, 503, and 504 server errors?

500 Internal Server Error is an unhandled exception or crash originating within the application code itself. 502 Bad Gateway indicates a reverse proxy (Nginx, Cloudflare, ALB) contacted the upstream application server, but received an invalid response or connection refusal. 503 Service Unavailable indicates the server is temporarily overloaded or undergoing maintenance (often returning a Retry-After header). 504 Gateway Timeout occurs when the reverse proxy connected to upstream, but upstream took longer than the configured timeout (e.g. 60s) to produce a response.

When should an API return 400 Bad Request versus 422 Unprocessable Content?

Return 400 Bad Request when the request has malformed syntax that prevents the server from even parsing the payload (e.g. invalid JSON with syntax errors, broken query parameter encoding, or missing required HTTP headers). Return 422 Unprocessable Content (RFC 9110 Section 15.5.21) when the payload syntax is perfectly valid (e.g. clean JSON), but contains semantic validation errors (e.g. email string fails regex, age number is negative, or password is too short).

What is the difference between 404 Not Found and 410 Gone for SEO and APIs?

404 Not Found indicates that the resource does not currently exist at the requested URI; search engines assume the removal might be accidental and will retry crawling the URL multiple times. In contrast, 410 Gone indicates the resource was intentionally and permanently removed with no forwarding address. Search engine bots (like Googlebot) interpret 410 as a definitive instruction to immediately purge the URL from search indexes and cease future crawling, saving crawl budget.

What HTTP status codes should a REST API return for POST, PUT, PATCH, and DELETE?

For POST (creation): return 201 Created with a Location header pointing to the new resource, or 202 Accepted if processing asynchronously. For PUT and PATCH (updates): return 200 OK with the updated entity, or 204 No Content if returning an empty body. For DELETE: return 204 No Content upon successful removal, or 202 Accepted if scheduled for deletion. For validation failures on any write verb: return 422 Unprocessable Content with error details.

How should an API implement 429 Too Many Requests for rate limiting?

When client request volume exceeds allowed thresholds, servers should return 429 Too Many Requests (RFC 6585) accompanied by a "Retry-After" header specifying the number of seconds or a GMT timestamp indicating when the client may retry. Well-architected APIs also include "X-RateLimit-Limit", "X-RateLimit-Remaining", and "X-RateLimit-Reset" headers so clients can proactively throttle requests before hitting limits.

Which HTTP status codes are cacheable by browsers and CDNs by default?

According to RFC 9110 and RFC 9111, status codes 200 (OK), 203 (Non-Authoritative Information), 204 (No Content), 206 (Partial Content), 300 (Multiple Choices), 301 (Moved Permanently), 404 (Not Found), 405 (Method Not Allowed), 410 (Gone), 414 (URI Too Long), and 501 (Not Implemented) can be cached by default unless explicit Cache-Control headers (such as no-store or private) override this behavior.

What is the standard format for returning error details in HTTP 4xx and 5xx responses?

RFC 9457 (superseding RFC 7807) establishes the "Problem Details for HTTP APIs" standard (Content-Type: application/problem+json). Instead of ad-hoc error schemas, compliant APIs return a standardized JSON structure with five canonical fields: "type" (URI reference identifying the problem type), "title" (short human-readable summary), "status" (the matching HTTP status code integer), "detail" (human-readable explanation specific to this occurrence), and "instance" (URI reference identifying the specific occurrence of the problem).