🌐 Web

HTTP Status Codes List

Meanings and differences across HTTP response codes from the 100s to the 500s
Reading the data

Read HTTP status codes by 100-level group

HTTP status codes are standard response codes that tell you how a server handled a request. Understanding the meanings of the 1xx, 2xx, 3xx, 4xx, and 5xx groups first makes individual errors such as 404, 429, 451, and 500 easier to distinguish.

How to read it

Search by code number, English name, meaning, or related keyword, then narrow the list by 100-level group or featured/special code filter. Select a code number to jump directly to that row.

What this page shows
  • Registered codes and standard reason phrases from the IANA HTTP Status Code Registry
  • Meanings, common situations, checks, and related codes by 100-level class
  • Detailed explanations for frequently searched codes such as 451, 429, 404, 500, and 503
Data basis

Compiled from the IANA HTTP Status Code Registry and IETF documents including RFC 9110, RFC 7725, and RFC 6585.

This page is a reference for HTTP protocol meanings. Legal, security, and operational decisions should also be checked against each service environment and official documentation.

Registered codes 64
Status classes 5
Featured codes 25
Special codes 21
1xx Informational 5 2xx Success 10 3xx Redirection 9 4xx Client error 29 5xx Server error 11
103 Early Hints 200 OK 206 Partial Content 301 Moved Permanently 302 Found 304 Not Modified 308 Permanent Redirect 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 410 Gone 413 Content Too Large 418 I'm a teapot 421 Misdirected Request 422 Unprocessable Content 425 Too Early 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 511 Network Authentication Required
🌐 Full HTTP status code list
64 codes

1xx Informational

Interim responses indicating that the request was received and processing is continuing.

5
Meaning Common situations What to check
100 Continue RFC 9110 The request headers were received, and the client may continue sending the request body. Used when a server confirms whether a large request body can proceed before the client sends it. Check the Expect: 100-continue header and the server's upload handling flow. Related: 417
101 Switching Protocols RFC 9110 The server accepted the protocol switch requested by the client. Seen when an HTTP connection is upgraded to another protocol such as WebSocket. Check the Upgrade header, Connection header, and whether proxies forward the upgrade correctly. Related: 426
102 Processing RFC 2518 The request was received and is still being processed, but the final response is not ready yet. Can be used by long-running WebDAV requests to reduce client-side timeout risk. Check whether a final response arrives separately and whether the client safely ignores interim responses. Related: 207, 208
104 Temporary Upload Resumption Supported IANA temporary registration A temporary registered status code indicating support for upload resumption. May appear in experimental flows that negotiate range-based resumption after a large upload is interrupted. Because this is an IANA temporary registration, confirm client and server support before using it in production. Related: 100, 201

2xx Success

Responses indicating that the request was understood and handled successfully.

10
Meaning Common situations What to check
200 OK RFC 9110 The request succeeded, and the response body contains the result. Used for most ordinary successful responses, including page views, API reads, and form results. Check that caching, response body format, and Content-Type match the actual result. Related: 201, 204
201 Created RFC 9110 The request succeeded and a new resource was created. Appropriate for POST requests that create posts, orders, accounts, files, or similar resources. Check whether the new resource location is provided through the Location header or response body. Related: 200, 202, 204
202 Accepted RFC 9110 The request was accepted, but processing has not completed yet. Used for asynchronous jobs, queued work, and batch operations whose results are decided later. Include a status URL, job ID, or retry guidance in the response when possible. Related: 200, 201, 204
203 Non-Authoritative Information RFC 9110 A proxy or transformation layer modified and forwarded the origin server's 200 response. Can be used when an intermediary provides a transformed representation or metadata. Check the original response, transformation policy, Warning headers, and cache headers together. Related: 200, 214
204 No Content RFC 9110 The request succeeded, but the response has no body. Used when delete, save, toggle, or similar actions succeed without needing a response body or navigation. Do not send a body with a 204 response, and confirm the client does not treat an empty response as an error. Related: 200, 205
205 Reset Content RFC 9110 The request succeeded, and the client may reset the input view. Can be used after form submission to tell the client to clear the fields on the same screen. It is rarely used in practice, so confirm that resetting the user interface is actually the desired experience. Related: 204
206 Partial Content RFC 9110 Only part of the resource is returned in response to a Range request. Common in video streaming, resumable downloads, and partial requests for large files. Check the Range, Content-Range, and Accept-Ranges headers along with CDN cache behavior. Related: 200, 416
207 Multi-Status RFC 4918 A WebDAV response carrying statuses for multiple sub-operations in one request. Used when several resources are processed together and each resource needs its own success or failure result. Parse per-resource statuses from the response body; ordinary REST APIs usually use their own result format instead. Related: 102, 208
208 Already Reported RFC 5842 Indicates that a WebDAV binding resource has already been reported and is not repeated. Used to reduce duplicate listings when the same resource is referenced through multiple paths in a WebDAV response. Confirm that the WebDAV client can handle 208 together with the 207 response body. Related: 207
226 IM Used RFC 3229 The server returned a result after applying an instance manipulation (IM). Defined for delta encoding and other change-based responses. A special cache and transfer flow using A-IM and IM headers is required, so it is rarely used on ordinary websites. Related: 200, 206

3xx Redirection

Responses indicating that another location or additional action is needed to complete the request.

9
Meaning Common situations What to check
300 Multiple Choices RFC 9110 The requested resource has multiple representations or choices. Can be used when the user or client must choose among language, format, or version alternatives for the same resource. In practice, redirects with a clear Location header such as 301, 302, 303, 307, and 308 are more common. Related: 301, 302
301 Moved Permanently RFC 9110 The resource has moved permanently to a new URL. Used for site restructuring, domain moves, and URL canonicalization when search engines should learn a permanent move. Check the Location header, cache duration, and whether internal links have been updated from the old URL. Related: 302, 308
302 Found RFC 9110 The resource is temporarily available at another URL. Used for non-permanent moves such as post-login navigation, temporary campaigns, and A/B tests. If the goal is to tell search engines about a permanent move, consider whether 301 or 308 is more appropriate. Related: 301, 303, 307
303 See Other RFC 9110 The result of the request should be retrieved with GET from another URL. Useful in the POST/Redirect/GET pattern after form processing, where the user is sent to a result or completion page. Understand that the method changes to GET, and verify the duplicate form submission prevention flow. Related: 302, 307
304 Not Modified RFC 9110 A conditional request found that the resource has not changed, so the cached copy can be used. Common when browsers or CDNs revalidate cache with If-None-Match or If-Modified-Since. Check that ETag, Last-Modified, and Cache-Control values behave as intended. Related: 200, 412
305 Use Proxy RFC 9110 A legacy status code instructing the client to use a proxy; it is now deprecated for security reasons. It is safest to treat this as unused on the modern web. Do not use it in new implementations; handle proxy policy through configuration or the network layer. Related: 407
306 Unused RFC 9110 A status code that was defined in the past but is now reserved and unused. Do not use it as a normal server response. If it appears in logs, check for intermediaries, test code, or non-standard implementations. Related: 305
307 Temporary Redirect RFC 9110 A temporary redirect that must preserve the request method and body. Clearer than 302 when POST, PUT, or another method must be preserved while sending the request to a temporary location. Confirm the client does not change the method to GET and that the Location target can handle the same request. Related: 302, 308
308 Permanent Redirect RFC 9110 A permanent redirect that must preserve the request method and body. Appropriate when permanently moving API endpoints or URLs where method preservation matters. Set Location carefully because search engines and client caches may remember it for a long time. Related: 301, 307

4xx Client Error

Responses indicating that the request cannot be handled because of client-side conditions such as syntax, authentication, authorization, or resource state.

29
Meaning Common situations What to check
400 Bad Request RFC 9110 The server cannot process the request because the syntax, parameters, headers, or body are invalid. Common with invalid JSON, missing required values, malformed URLs, or abnormal headers. Check the request body format, Content-Type, query parameters, and server validation logs. Related: 422
401 Unauthorized RFC 9110 Authentication is required or the provided credentials are invalid. Used when a login token is missing, an API key expired, or the Authorization header is incorrect. Check the WWW-Authenticate header, token expiry, authentication scheme, and whether cookies are sent. Related: 403, 407
402 Payment Required RFC 9110 Reserved for payment-required scenarios, but its standard meaning is not widely established. Some APIs and payment services use it unofficially for payment, credit, or subscription problems. Check the service-specific API documentation for the actual meaning of 402 and the recovery path. Related: 403, 429
403 Forbidden RFC 9110 The server understood the request but refuses to allow access. Common with insufficient permissions, IP blocks, administrative policy, or access to private resources. Check authorization policy, ACLs, WAF rules, file permissions, and routing rules separately from authentication. Related: 401, 404, 451
404 Not Found RFC 9110 The requested resource cannot be found, or the server is not revealing whether it exists. Most common with URL typos, deleted pages, incorrect routes, or intentionally hidden resources. Check internal links, sitemaps, redirects, routing tables, and replacement URLs for deleted content. Related: 410, 403, 451
405 Method Not Allowed RFC 9110 The resource exists, but the requested HTTP method is not allowed. Occurs when POST is sent to a GET-only URL or when an API route is configured for different methods. Check the Allow header, router method definitions, and proxy method restriction policies. Related: 404, 501
406 Not Acceptable RFC 9110 The server cannot provide a representation matching the client's Accept headers. Can occur when the client requests only unsupported media types, languages, or encodings. Check the Accept, Accept-Language, and Accept-Encoding headers and the server's content negotiation settings. Related: 415
407 Proxy Authentication Required RFC 9110 Authentication is required before the client can use the proxy. Seen in corporate networks, security proxies, and gateway authentication environments. Check Proxy-Authenticate and Proxy-Authorization headers and the network proxy configuration. Related: 401, 305
408 Request Timeout RFC 9110 The server did not receive the complete client request within the time it was willing to wait. Can happen with slow networks, large uploads, keep-alive timeouts, or load balancer timeouts. Check client retry behavior, upload size, keep-alive settings, and proxy timeout values. Related: 504
409 Conflict RFC 9110 The request conflicts with the current state of the resource. Often used for duplicate creation, version conflicts, concurrent edits, or invalid state transitions. Check resource versions, ETags, duplicate keys, and business state transition rules. Related: 412, 422
410 Gone RFC 9110 The resource existed in the past but has been permanently removed. More specific than 404 when you want to clearly tell search engines and clients that a page was deleted. Use 301 if there is a replacement URL; use 410 with sitemap cleanup when permanent removal is correct. Related: 404, 301
411 Length Required RFC 9110 The server rejects the request because it does not include Content-Length. Can occur when a server or gateway must know the request body length in advance. Check Content-Length, Transfer-Encoding, and the streaming behavior of the client library. Related: 413
412 Precondition Failed RFC 9110 A precondition in a conditional request, such as If-Match, failed. Used for concurrent edit prevention, cache revalidation, and ETag-based updates. Compare If-Match, If-None-Match, and If-Unmodified-Since with the current resource version. Related: 304, 409, 428
413 Content Too Large RFC 9110 The request body is larger than the server is willing to accept. Common with file upload limits, JSON body size limits, and proxy body size restrictions. Check upload limits across the server, proxy, CDN, and application. Related: 411, 431
414 URI Too Long RFC 9110 The request URI is longer than the server can process. Can happen with very long query strings, faulty redirect loops, or excessive data placed in a GET URL. Move long data into a POST body and check URI length limits in proxies and servers. Related: 400, 431
415 Unsupported Media Type RFC 9110 The server does not support the media type of the request body. Occurs when a JSON API receives the wrong Content-Type or an unsupported file format is uploaded. Check Content-Type, file extension, multipart settings, and whether the server parser is registered. Related: 406, 422
416 Range Not Satisfiable RFC 9110 The requested Range cannot be served because it does not fit the resource size. Occurs in resumable downloads or streaming when the requested range is outside the file size. Check the Range header, Content-Range, file size, and stale cached metadata. Related: 206
417 Expectation Failed RFC 9110 The server cannot satisfy the expectation given in the Expect header. Can occur when a server or proxy does not support expectations such as Expect: 100-continue. Remove the Expect header or confirm that the server supports 100 Continue handling. Related: 100
422 Unprocessable Content RFC 9110 The request syntax is valid, but the content is semantically unprocessable. Common for API validation failures, business rule violations, and invalid field values. Decide in your API rules whether 400 means format errors and 422 means semantic or validation errors. Related: 400, 409, 415
423 Locked RFC 4918 The target resource is locked, so the request cannot be processed. Used for file edit locks, collaborative documents, and WebDAV resource locks. Check the lock owner, lock expiry, unlock API, and conflict handling policy. Related: 409, 424
424 Failed Dependency RFC 4918 The current request cannot be performed because a previous dependent operation failed. Used when multiple operations depend on one another and failure of an earlier operation causes a later one to fail. Make the failed prior operation and the dependency relationship clear in the response body. Related: 207, 423
426 Upgrade Required RFC 9110 The server requires the client to upgrade protocols before it will handle the request. Used when a specific upgrade is required, such as an HTTP version, TLS, or WebSocket. Check the Upgrade header, supported protocols, and whether proxies forward upgrade requests. Related: 101
428 Precondition Required RFC 6585 The server requires a conditional request header. Used to prevent lost updates from concurrent edits by requiring a condition such as If-Match. Provide API documentation and error messages that tell clients to read the ETag and update with If-Match. Related: 412, 409
429 Too Many Requests RFC 6585 The client sent too many requests within a given time period. Common with API rate limits, login attempt limits, bot blocking, and excessive refresh behavior. Check Retry-After, rate limit headers, per-user or per-token limits, and backoff strategy. Related: 403, 503
431 Request Header Fields Too Large RFC 6585 The overall request headers or a specific header field are too large. Can occur when cookies become too large or when authentication tokens, tracking headers, or proxy-added headers accumulate. Reduce Cookie size, Authorization header size, and headers added by proxy chains. Related: 400, 413, 414

5xx Server Error

Responses indicating that the server or gateway failed to handle an otherwise valid request.

11
Meaning Common situations What to check
500 Internal Server Error RFC 9110 A general server error indicating that the request could not be handled because of an internal failure. Used when detailed errors such as exceptions, missing configuration, database failures, or template render failures should not be exposed to the client. Check application logs, error tracking, recent deployments, and dependent service health. Related: 502, 503, 504
501 Not Implemented RFC 9110 The server does not support the functionality required to handle the request. Used when an unsupported HTTP method or a server feature that has not been implemented is requested. 405 means the method is forbidden for that resource; 501 is closer to the server not knowing the capability at all. Related: 405
502 Bad Gateway RFC 9110 A gateway or proxy received an invalid response from an upstream server. Common with origin server connection issues behind a CDN, load balancer, or reverse proxy. Check origin health, DNS, TLS, proxy upstream settings, and response header size and format. Related: 500, 503, 504
503 Service Unavailable RFC 9110 The server is temporarily unable to handle the request. Common during maintenance, overload, deployments, backend outages, and autoscaling delays. Check Retry-After, health checks, autoscaling, queue backlog, and maintenance page configuration. Related: 429, 500, 502, 504
504 Gateway Timeout RFC 9110 A gateway or proxy did not receive a timely response from an upstream server. Common with origin server latency, slow database queries, external API delays, and load balancer timeouts. Check upstream timeout values, application processing time, database or external API response time, and retry policy. Related: 408, 502, 503
505 HTTP Version Not Supported RFC 9110 The server does not support the HTTP version used in the request. Can occur with old clients, broken proxies, or server-side HTTP version restrictions. Check the client HTTP version, TLS/ALPN negotiation, and proxy protocol translation settings. Related: 426
506 Variant Also Negotiates RFC 2295 A transparent content negotiation configuration error caused an internal negotiation loop. Used when server content negotiation is misconfigured and the chosen variant is itself configured to negotiate. Check content negotiation settings, variant mappings, and server configuration files. Related: 300, 406
507 Insufficient Storage RFC 4918 The server cannot allocate the storage needed to complete the request. Can occur with WebDAV, file uploads, storage quota exhaustion, or lack of disk space. Check disk usage, temporary file storage, user quotas, and object storage errors. Related: 413, 500
508 Loop Detected RFC 5842 The server detected an infinite loop while processing the request. Can be used when a WebDAV Depth request or internal reference structure contains a cycle. Check the resource reference graph, symbolic links, WebDAV bindings, and recursion limits. Related: 508
510 Not Extended RFC 2774 Additional extensions are required for the request to be processed. Defined by the HTTP extension framework, but rarely used in ordinary web services. Check the documentation for the API or server extension requirements involved. Related: 501

Details for frequently searched HTTP codes

Find a code quickly in the table, then use the explanations below to compare it with similar codes.

HTTP 451 Unavailable For Legal Reasons

451 is a 4xx status code that clearly signals that access is unavailable for legal reasons.

HTTP 451 is used when a server, search engine, proxy, or intermediary cannot provide a resource because of a legal demand. It is not just a lack of permission; it signals that an external legal requirement such as a court order, government request, copyright action, or local regulation is behind the restriction.

When you see 451 in search results or a browser, it is more accurate to understand that the page is not being provided for legal reasons in the current request location or service policy, rather than assuming it has technically disappeared. When possible, service providers should explain the blocking party or legal demand in the response body so users can understand the situation.

Difference from 403 403 means access is forbidden by permission or server policy; 451 is used when the reason for that restriction is a legal requirement.
Difference from 404 404 means the resource cannot be found or its existence is hidden; 451 more strongly means the resource exists or is known but cannot be provided for legal reasons.
Difference from 410 410 means the resource was permanently removed; 451 means access is restricted regardless of whether the resource was deleted.

HTTP 429 Too Many Requests

429 means a request limit was exceeded, and it is especially common in APIs and login protection.

429 is used when a client sends too many requests in a short period. It is tied to service stability and abuse prevention policies such as usage limits, bot defense, login attempt limits, and free-plan API quotas.

Servers should provide Retry-After or rate limit headers when possible so clients know when to try again. Clients should use exponential backoff and queueing rather than immediately repeating requests.

Difference from 403 403 means access itself is forbidden, while 429 may become allowed again after time passes or usage recovers.
Difference from 503 503 means the server is temporarily unable to handle requests; 429 more specifically means a particular client or token exceeded a request quota.

HTTP 404 Not Found

404 is the most common web error code, and URL and content state should be checked first.

404 means the server could not find the requested resource. Users usually interpret it as a URL typo or deleted page, but servers may also return 404 to avoid revealing whether a protected resource exists.

For search visibility, check broken internal links, old sitemaps, and missing replacement pages for deleted content. If a clear replacement exists, 301 may be appropriate; if the resource is permanently deleted, 410 is also an option.

Difference from 410 404 is a general not-found response, while 410 signals that the resource existed before and is permanently gone.
Difference from 403 403 means the server found the resource but refuses access; 404 means it was not found or the server is not revealing whether it exists.

HTTP 500 Internal Server Error

500 is a broad server-side error meaning an exception or failure occurred while processing the request.

500 is used when a problem occurs in server-side logic, configuration, dependent services, or data processing rather than in the client request format. It is often returned as a generalized error code to avoid exposing detailed exceptions to users.

In operations, check recent deployments, application logs, error tracking, database connections, and missing environment variables first. If the same request repeatedly produces 500, also inspect input validation and exception handling paths.

Difference from 502 500 is an internal error in the current server, while 502 means a gateway received an invalid response from an upstream server.
Difference from 503 503 is better suited for temporary unavailability such as maintenance or overload.

HTTP 503 Service Unavailable

503 means the server is temporarily unable to handle the request.

503 is used when a service temporarily cannot accept requests because of maintenance, overload, deployment, backend failures, or autoscaling delay. For search engines, it can signal a temporary problem, so scheduled maintenance is often better represented with 503 than 500.

Include a Retry-After header when possible to indicate when the client should try again. Also check load balancer health checks, queue backlog, instance count, and dependent service failures.

Difference from 500 500 covers internal errors broadly, while 503 more clearly states that the server is temporarily unable to process requests.
Difference from 429 429 means the requesting client sent too many requests, while 503 is closer to the service as a whole, or part of it, losing processing capacity.

HTTP status codes are standardized signals for communication meaning. The actual cause should be checked together with application logs, proxy/CDN settings, authentication policies, cache headers, and deployment history.

Sources and licenses

Data sources and terms of use

This page is based on public data from the original providers below. Each dataset follows the original provider's license or terms of use.

Source Dataset/API Terms Onul Works processing
IANA HTTP Status Code Registry Terms Reorganizes IANA registered codes and IETF RFC descriptions into 100-level groups, search tags, and featured code explanations.
IETF / RFC Editor HTTP Semantics and status code RFCs Terms Reorganizes IANA registered codes and IETF RFC descriptions into 100-level groups, search tags, and featured code explanations.

Normalization, translation, merging, caching, or unit conversion by Onul Works does not imply warranty or endorsement by the original providers.