Web Development

HTTP Status Codes: Cheatsheet for Devs

Master the language of the web with our comprehensive guide to HTTP status codes. Learn what they mean and how to use them effectively in your projects.

HTTP Status Codes: Cheatsheet for Devs

HTTP status codes are the silent communicators of the web, conveying crucial information about the outcome of requests between clients and servers. As a developer, understanding these codes is essential for building robust applications, debugging issues, and optimizing user experiences. In this comprehensive guide, we'll explore the importance of HTTP status codes and provide a detailed cheatsheet to help you navigate the web's response language.

Why HTTP Status Codes Matter

HTTP status codes are more than just numbers; they're a standardized way for servers to communicate the results of client requests. Here's why they're crucial:

  1. Error Diagnosis: Status codes help quickly identify and troubleshoot issues in web applications.
  2. User Experience: Proper use of status codes enables better error handling and user feedback.
  3. SEO Impact: Search engines use status codes to understand website structure and content availability.
  4. API Design: Well-implemented status codes are essential for creating clear and effective APIs.
  5. Performance Optimization: Certain status codes facilitate caching and resource management.

Try Our URL Redirect Checker Tool

We've created a handy URL Redirect Checker tool that allows you to trace the redirect path of any URL.

This tool is particularly useful for:

  • SEO professionals analyzing redirect chains
  • Developers debugging redirection issues
  • Anyone curious about the journey a URL takes before reaching its final destination

Try the URL Redirect Checker

Our tool will show you each step of the redirect process, including the status codes encountered along the way. It's a practical way to see HTTP status codes in action and understand how they affect web navigation.

The Anatomy of HTTP Status Codes

HTTP status codes are three-digit numbers grouped into five classes, each serving a specific purpose:

  • 1xx: Informational responses
  • 2xx: Successful responses
  • 3xx: Redirection messages
  • 4xx: Client error responses
  • 5xx: Server error responses

Let's dive into each category and explore the status codes you'll encounter.

1XX Informational Responses

These status codes indicate that the server has received the request and is continuing to process it.

100 Continue

This interim response indicates that everything so far is OK and that the client should continue with the request or ignore it if it's already finished. It's often used when the client is sending a large request body and wants to know if the server is willing to accept it before sending the entire payload.

101 Switching Protocols

This code is sent in response to an Upgrade request header from the client and indicates the protocol the server is switching to. It's commonly used in WebSocket connections, where the client requests to upgrade from HTTP to the WebSocket protocol.

102 Processing (WebDAV)

This status code is used to inform the client that the server has accepted the complete request but has not yet completed it. This prevents the client from timing out and assuming the request was lost.

103 Early Hints

This status code is primarily intended to be used with the Link header, letting the user agent start preloading resources while the server prepares a response. It can help improve perceived page load times by allowing the browser to start fetching resources before the main response is ready.

2XX Successful Responses

These status codes indicate that the client's request was successfully received, understood, and accepted by the server.

200 OK

This is the standard response for successful HTTP requests. The actual response will depend on the request method used. For example, for a GET request, the response will contain an entity corresponding to the requested resource. For a POST request, the response will contain an entity describing or containing the result of the action.

201 Created

This status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. It's typically used in response to POST requests or some PUT requests. The new resource's URI(s) are usually specified in the response's Location header.

202 Accepted

This response code means the request has been accepted for processing, but the processing has not been completed. It's often used for asynchronous operations. The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed.

203 Non-Authoritative Information

This response code means the returned metadata is not exactly the same as is available from the origin server, but is collected from a local or a third-party copy. This is used for mirrors or backups of another resource. Except for that specific case, the 200 OK response is preferred to this status.

204 No Content

This status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. This is often used as a response to a successful DELETE request.

205 Reset Content

This response code tells the client to reset the document view. This can be useful for web applications that need to refresh the user interface after a form submission.

206 Partial Content

This status code is used when the client has sent a range header to request only part of a resource. It's commonly used for resuming interrupted downloads or splitting a large download into multiple simultaneous streams.

207 Multi-Status (WebDAV)

This status code provides status for multiple independent operations. It's used in WebDAV (Web Distributed Authoring and Versioning) to allow the client to issue multiple requests in a single HTTP request.

208 Already Reported (WebDAV)

This status code is used inside a DAV: propstat response element to avoid repeatedly enumerating the internal members of multiple bindings to the same collection. It's a WebDAV-specific status code.

226 IM Used (HTTP Delta encoding)

The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. This status code is used in HTTP Delta encoding to indicate that the server has fulfilled the request and the response is a representation of the result of one or more instance-manipulations applied to the current instance.

3XX Redirection

These status codes indicate that further action needs to be taken by the user agent in order to fulfill the request. The action required may sometimes be carried out by the user agent without interaction with the user.

300 Multiple Choices

This status code indicates that the request has more than one possible response. The user agent or user should choose one of them. There is no standardized way of choosing one of the responses, but HTML links to the possibilities are recommended so the user can pick.

301 Moved Permanently

This status code means that the URL of the requested resource has been changed permanently. The new URL is given in the response. This status code is commonly used for URL redirection. Search engines update their links to the resource when encountering this status code.

302 Found

This status code indicates that the URI of requested resource has been changed temporarily. Further changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests. This status code is similar to 301, but it does not allow changing the request method from POST to GET.

303 See Other

This status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header, which is intended to provide an indirect response to the original request. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource.

304 Not Modified

This status code is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response. It's commonly used to reduce bandwidth usage.

305 Use Proxy

This status code is no longer used. It indicated that the requested resource must be accessed through the proxy given by the Location header. It was deprecated due to security concerns regarding in-band configuration of a proxy.

307 Temporary Redirect

This status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. This is similar to 302, but does not allow the HTTP method to change.

308 Permanent Redirect

This status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. This is similar to 301, but does not allow the HTTP method to change.

4XX Client Errors

These status codes are intended for situations in which the client seems to have erred. They indicate that the request contains bad syntax or cannot be fulfilled.

400 Bad Request

This status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error. This could be due to malformed request syntax, invalid request message framing, or deceptive request routing.

401 Unauthorized

This status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field containing at least one challenge applicable to the target resource.

403 Forbidden

This status code indicates that the server understood the request but refuses to authorize it. Unlike 401, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.

404 Not Found

This status code indicates that the server can't find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 to hide the existence of a resource from an unauthorized client.

405 Method Not Allowed

This status code indicates that the request method is known by the server but is not supported by the target resource. For example, an API may forbid DELETE-ing a resource.

406 Not Acceptable

This status code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers. This is often used when the server doesn't support the media type requested by the client.

407 Proxy Authentication Required

This status code is similar to 401 but indicates that the client must first authenticate itself with the proxy.

408 Request Timeout

This status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. The client may repeat the request without modifications at any later time.

409 Conflict

This status code indicates a request conflict with the current state of the target resource. This is often used in PUT requests when uploading a file that is older than the existing one on the server, resulting in a version control conflict.

410 Gone

This status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If you don't know whether this condition is temporary or permanent, a 404 status code should be used instead.

411 Length Required

This status code indicates that the server refuses to accept the request without a defined Content-Length header.

412 Precondition Failed

This status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server.

413 Payload Too Large

This status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request.

414 URI Too Long

This status code indicates that the server is refusing to service the request because the request-target is longer than the server is willing to interpret. This can occur when a client has improperly converted a POST request to a GET request with long query information.

415 Unsupported Media Type

This status code indicates that the server is refusing to service the request because the payload is in a format not supported by this method on the target resource. This often occurs when the client sends a content type that the server doesn't support.

416 Range Not Satisfiable

This status code indicates that none of the ranges in the request's Range header field overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges.

417 Expectation Failed

This status code indicates that the expectation given in the request's Expect header field could not be met by at least one of the inbound servers.

418 I'm a teapot

This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. It is often used as an Easter egg in websites.

421 Misdirected Request

This status code indicates that the request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

422 Unprocessable Entity (WebDAV)

This status code means the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

423 Locked (WebDAV)

This status code means the source or destination resource of a method is locked.

424 Failed Dependency (WebDAV)

This status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed.

425 Too Early

This status code indicates that the server is unwilling to risk processing a request that might be replayed.

426 Upgrade Required

This status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.

428 Precondition Required

This status code indicates that the origin server requires the request to be conditional.

429 Too Many Requests

This status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). This is often used to prevent abuse or overload of server resources.

431 Request Header Fields Too Large

This status code indicates that the server is unwilling to process the request because its header fields are too large. The request may be resubmitted after reducing the size of the request header fields.

This status code indicates that the server is denying access to the resource as a consequence of a legal demand. The server in question might not be an origin server. This type of legal demand typically most directly affects the operations of ISPs and search engines.

5XX Server Errors

These status codes indicate that the server failed to fulfill a valid request. They are used when the server is aware that it has encountered an error or is otherwise incapable of performing the request.

500 Internal Server Error

This status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. This is a generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

501 Not Implemented

This status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

502 Bad Gateway

This status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request. This typically occurs when an upstream service is down or unreachable.

503 Service Unavailable

This status code indicates that the server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service.

504 Gateway Timeout

This status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request. This typically occurs when the upstream service is slow or unresponsive.

505 HTTP Version Not Supported

This status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. This might occur when a client uses a newer HTTP version that the server doesn't support.

506 Variant Also Negotiates

This status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

507 Insufficient Storage (WebDAV)

This status code indicates that the server is unable to store the representation needed to complete the request.

508 Loop Detected (WebDAV)

This status code indicates that the server detected an infinite loop while processing the request.

510 Not Extended

This status code indicates that further extensions to the request are required for the server to fulfill it.

511 Network Authentication Required

This status code indicates that the client needs to authenticate to gain network access. This status is not generated by origin servers, but by intercepting proxies that control access to the network.

Conclusion

HTTP status codes are an integral part of web communication, providing valuable insights into the outcome of client-server interactions. By mastering these codes, developers can create more robust applications, improve error handling, and enhance overall user experience. Whether you're building APIs, troubleshooting web applications, or optimizing for search engines, a solid understanding of HTTP status codes is an invaluable skill in your developer toolkit.

Remember, while this cheatsheet covers a comprehensive list of status codes, there may be additional specialized codes for specific situations. Always refer to the official HTTP specifications for the most up-to-date and comprehensive information.

Additional Resources

To further enhance your understanding of HTTP status codes and their practical applications, consider exploring these resources:

  1. MDN Web Docs: HTTP response status codes
  2. RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
  3. HTTP Cats - A fun way to visualize HTTP status codes
  4. HTTP Status Dogs - Another humorous take on status codes

Best Practices for Using HTTP Status Codes

  1. Be specific: Use the most appropriate status code for each situation to provide clear feedback.
  2. Consistent usage: Maintain consistency in status code usage across your application or API.
  3. Error messages: Accompany error status codes with helpful error messages in the response body.
  4. Security considerations: Be cautious about revealing too much information in error responses.
  5. Caching headers: Use appropriate caching headers in conjunction with status codes like 304 Not Modified.

Common Pitfalls to Avoid

  1. Overusing 200 OK for error conditions
  2. Misusing 401 Unauthorized and 403 Forbidden
  3. Neglecting to implement proper redirect chains (301, 302, 307, 308)
  4. Ignoring the semantic differences between similar status codes (e.g., 403 vs. 404)
  5. Failing to handle unexpected status codes gracefully in client applications

By mastering HTTP status codes and following these best practices, you'll be well-equipped to build more robust, efficient, and user-friendly web applications and APIs.

Remember, effective use of status codes is just one aspect of creating great web experiences. Continue to explore other areas of web development, such as performance optimization, security best practices, and emerging web technologies, to stay at the forefront of your field.