HTTP Status Codes Reference

Understanding HTTP: The Foundation of the Web

HTTP (Hypertext Transfer Protocol) is the application-layer protocol that powers the World Wide Web. Every time you visit a webpage, submit a form, or call an API, your browser (or application) sends an HTTP request to a server, and the server sends back an HTTP response. Each response includes a three-digit status code that tells the client what happened with the request.

Understanding HTTP status codes is essential for web developers, backend engineers, DevOps professionals, and anyone who works with APIs. The status code is often the first piece of diagnostic information you see when debugging a failing request, and choosing the correct status code in your API responses is critical for building well-designed, standards-compliant services.

The HTTP Request-Response Cycle

The HTTP communication model is straightforward: the client sends a request, and the server sends a response. Here is what a typical cycle looks like:

The client (browser, mobile app, CLI tool) opens a TCP connection to the server (or reuses an existing one).
The client sends an HTTP request containing a method (GET, POST, PUT, DELETE, etc.), a path (/api/users), headers (Content-Type, Authorization, etc.), and optionally a body.
The server processes the request and sends back a response containing a status code, headers, and optionally a body.
The client interprets the status code and response body to determine the next action.

The status code is the server’s concise summary of what happened. It allows the client to programmatically handle different outcomes without parsing the response body.

Status Code Categories at a Glance

HTTP status codes are grouped into five categories, each defined by the first digit:

1xx (Informational): The request was received and the server is continuing the process. These are interim responses, rarely seen in everyday web development but important for protocol negotiation and performance optimization (e.g., 103 Early Hints).
2xx (Success): The request was successfully received, understood, and accepted. The most common is 200 OK. Other important codes include 201 Created (for resource creation) and 204 No Content (for successful operations with no response body).
3xx (Redirection): The client needs to take additional action to complete the request, typically by following a redirect to a different URL. Key codes include 301 (permanent redirect), 302 (temporary redirect), and 304 (cache hit).
4xx (Client Error): The request contains bad syntax or cannot be fulfilled. The client made an error. Common codes include 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), and 429 (rate limited).
5xx (Server Error): The server failed to fulfill a valid request. The error is on the server side. Common codes include 500 (internal server error), 502 (bad gateway), and 503 (service unavailable).

Most Commonly Encountered Status Codes

200 OK

The universal success response. For GET requests, it means the requested resource is in the response body. For POST requests, it typically means the action was completed and the result is included. When in doubt about which 2xx code to use, 200 is the safe default.

301 Moved Permanently

Critical for SEO. When you change a URL permanently, a 301 redirect tells search engines to transfer all link equity (PageRank) from the old URL to the new one. This is the correct choice when restructuring your site, changing domain names, or consolidating duplicate content. Search engines typically follow 301 redirects and update their index within days.

302 Found (Temporary Redirect)

Used when a resource is temporarily available at a different URL. Unlike 301, search engines keep the original URL in their index because the redirect is not permanent. Common use cases include A/B testing, maintenance redirects, and geo-based routing.

404 Not Found

The most recognizable error code on the web. It means the server cannot find the requested resource. Every website should have a custom 404 page that helps users navigate back to useful content. From an SEO perspective, excessive 404 errors can indicate crawl issues that search engines may penalize.

500 Internal Server Error

The generic server-side error. It means something went wrong on the server, but the server cannot be more specific about what. In production, this often indicates unhandled exceptions, configuration errors, or infrastructure failures. Good monitoring and alerting on 500 responses is essential for maintaining service reliability.

HTTP Status Codes and SEO

Search engines like Google pay close attention to HTTP status codes when crawling and indexing your site:

200: The page is healthy and eligible for indexing.
301: Link equity is transferred to the new URL. Google consolidates indexing signals.
302: Google may or may not transfer link equity. The original URL remains in the index.
404: The page is removed from the index over time. Excessive 404s can lower your crawl efficiency.
410: A stronger signal than 404. Google removes the page from the index faster.
503: Tells search engines the downtime is temporary. Use during maintenance to prevent de-indexing.
5xx: Persistent server errors can cause Google to reduce crawl rate and eventually drop pages from the index.

A well-structured redirect strategy using 301s and 308s is one of the most important technical SEO practices. Redirect chains (multiple redirects in sequence) should be avoided as they waste crawl budget and can dilute link equity.

REST API Status Code Best Practices

When designing REST APIs, choosing the right status code makes your API self-documenting and easier to consume:

GET: Return 200 with the resource, or 404 if not found.
POST (create): Return 201 with the created resource and a Location header pointing to it.
PUT/PATCH (update): Return 200 with the updated resource, or 204 if no body is needed.
DELETE: Return 204 on success.
Validation errors: Return 422 with a structured error body describing which fields failed validation.
Authentication errors: Return 401 when no valid credentials are provided, 403 when credentials are valid but permissions are insufficient.
Rate limiting: Return 429 with a Retry-After header.

Avoid using 200 for everything and encoding errors in the response body. Clients rely on status codes for control flow, and HTTP libraries throw exceptions for 4xx/5xx codes, making error handling more natural.

Custom Error Pages

Every production website should implement custom error pages for at least 404 and 500 status codes. A good error page should:

Maintain your site’s branding and navigation.
Clearly explain what went wrong in plain language.
Provide useful actions: a link to the homepage, a search bar, or popular pages.
Return the correct HTTP status code (not a 200 with “error” content, which is called a soft 404).

Soft 404s — pages that return a 200 status code but display error content — confuse search engines and waste crawl budget. Google Search Console specifically flags soft 404s as issues to fix.

Debugging with HTTP Status Codes

When troubleshooting web applications, the status code is your first clue:

4xx errors point to client-side issues: wrong URL, missing authentication, invalid request body, or rate limiting. Check the request you are sending.
5xx errors point to server-side issues: application crashes, database failures, timeout configurations, or deployment problems. Check server logs.
Redirect loops (too many redirects) indicate misconfigured redirect rules, often caused by conflicting rules in your web server, CDN, and application.

Browser developer tools (Network tab), curl -v, and API clients like Postman or Insomnia are essential tools for inspecting HTTP responses and their status codes.

HTTP/1.1, HTTP/2, and HTTP/3

HTTP status codes are consistent across all versions of the HTTP protocol. Whether you are using HTTP/1.1, HTTP/2, or HTTP/3 (QUIC-based), the same status codes apply with the same semantics:

HTTP/1.1: Text-based protocol. Status codes appear in the response line (e.g., HTTP/1.1 200 OK).
HTTP/2: Binary protocol with multiplexing. Status codes are sent as the :status pseudo-header. The reason phrase (e.g., “OK”) is no longer transmitted, only the numeric code.
HTTP/3: Uses QUIC (UDP-based) instead of TCP for transport. Status codes work identically to HTTP/2.

The move from HTTP/1.1 to HTTP/2 and HTTP/3 improved performance (multiplexing, header compression, 0-RTT handshakes) but did not change the semantics of status codes. Your application code does not need to change based on the HTTP version.

Frequently Asked Questions

What is the difference between 401 and 403?

A 401 Unauthorized response means the client has not authenticated (no credentials or invalid credentials). A 403 Forbidden response means the client is authenticated but does not have permission to access the resource. Think of 401 as “who are you?” and 403 as “I know who you are, but you cannot access this.”

Should I use 301 or 302 for redirects?

Use 301 when the redirect is permanent (URL changed forever). Use 302 when the redirect is temporary (the original URL will be used again in the future). For SEO purposes, 301 transfers link equity to the new URL, while 302 keeps it on the original URL.

What does 418 I’m a teapot mean?

Status code 418 was defined as an April Fools’ joke in RFC 2324 (Hyper Text Coffee Pot Control Protocol, 1998). It has no real-world use in HTTP, but many developers enjoy including it as an Easter egg in their APIs. It is not part of the official HTTP/1.1 standard.

How do I handle status codes in JavaScript fetch?

The Fetch API does not reject promises for HTTP error status codes (4xx and 5xx). You must check response.ok or response.status manually. Libraries like Axios, on the other hand, throw errors for non-2xx responses automatically, which many developers find more convenient for error handling.

What is the most common HTTP status code?

By volume, 200 OK is overwhelmingly the most common status code, followed by 304 Not Modified (cache hits). Among error codes, 404 Not Found is the most frequently encountered by end users.

Can I create custom HTTP status codes?

Technically, HTTP allows any three-digit integer as a status code, and clients should handle unknown codes based on the first digit (e.g., an unknown 4xx is treated like 400). However, using non-standard codes is strongly discouraged because clients, proxies, and monitoring tools may not handle them correctly. Use the standard codes and communicate additional detail in the response body.