HTTP Status Codes Reference

About HTTP Status Codes Reference

How HTTP Status Codes Work

Every HTTP response begins with a three-digit status code. The first digit defines which of the five categories the response belongs to, while the remaining two digits identify the specific condition. When a browser or API client makes a request, the server returns one of these codes along with optional headers and a body. The client then decides what to do based on the code - display content, follow a redirect, show an error, or retry the request.

RFC 9110 consolidates the previous RFC 7230-7235 series into a single specification for HTTP semantics. It defines the meaning of each status code regardless of whether HTTP/1.1, HTTP/2, or HTTP/3 is used as the transport. The IANA Hypertext Transfer Protocol Status Code Registry at iana.org/assignments/http-status-codes is the authoritative list, and any new codes require IETF Review before registration.

Status Code Categories

Range	Category	Meaning	Examples
1xx	Informational	Request received, processing continues	100 Continue, 101 Switching Protocols, 103 Early Hints
2xx	Success	Request received, understood, and accepted	200 OK, 201 Created, 204 No Content, 206 Partial Content
3xx	Redirection	Further action needed to complete request	301 Moved Permanently, 304 Not Modified, 307 Temporary Redirect
4xx	Client Error	The request contains an error	400 Bad Request, 404 Not Found, 429 Too Many Requests
5xx	Server Error	The server failed to fulfil a valid request	500 Internal Server Error, 503 Service Unavailable

Most Used Status Codes for REST APIs

Building a REST API means picking the right status code for every endpoint. Using generic 200 for everything technically works, but it makes debugging harder and violates HTTP semantics. Here are the codes that cover the vast majority of API interactions.

Code	Name	When to Use	Typical HTTP Method
200	OK	General success response	GET, PUT, PATCH
201	Created	New resource successfully created	POST
204	No Content	Success with no response body	DELETE, PUT
400	Bad Request	Invalid request body, missing parameters	Any
401	Unauthorized	Missing or invalid authentication	Any
403	Forbidden	Authenticated but not authorised for this resource	Any
404	Not Found	Resource does not exist	Any
409	Conflict	Request conflicts with current state (duplicate, version mismatch)	POST, PUT
422	Unprocessable Content	Request is well-formed but semantically invalid	POST, PUT
429	Too Many Requests	Rate limit exceeded	Any
500	Internal Server Error	Unexpected server failure	Any
503	Service Unavailable	Server temporarily down (maintenance, overload)	Any

Worked example: A POST to /api/users with a valid body creates a new user. The server returns 201 Created with a Location: /api/users/42 header pointing to the new resource. If the email already exists, the server returns 409 Conflict. If the request body is missing required fields, it returns 400 Bad Request. If the auth token is expired, it returns 401 Unauthorized with a WWW-Authenticate header.

Common Confusion: 401 vs 403

This is one of the most frequently misused pairs of status codes. The names are misleading - 401 is called "Unauthorized" but actually means "unauthenticated", while 403 "Forbidden" means "unauthorised". Here is the practical difference.

Aspect	401 Unauthorized	403 Forbidden
Authentication	Not provided or invalid	Valid (user is known)
Problem	"Who are you?"	"I know who you are, but you can't do this"
Fix	Provide valid credentials	Request access from admin
Should include	WWW-Authenticate header	Optionally an error message
Retry with auth?	Yes - might fix it	No - re-authenticating won't help

RFC 9110 Section 15.5.2 specifies that a 401 response must include a WWW-Authenticate header indicating which authentication scheme the server expects (e.g. Bearer, Basic). Omitting this header is technically a spec violation, though many APIs skip it in practice.

Redirect Codes Explained

Redirect codes tell the client that the resource has moved. The differences between them matter for SEO and for preserving the original HTTP method (GET, POST, etc.) during the redirect.

Code	Name	Permanent?	Method Preserved?	Use Case
301	Moved Permanently	Yes (cached)	May change to GET	Domain change, URL restructure (SEO-friendly)
302	Found	No	May change to GET	Temporary redirect (legacy, ambiguous)
303	See Other	No	Always changes to GET	Redirect after POST (form submission)
307	Temporary Redirect	No	Yes (preserved)	Temporary redirect that must keep the HTTP method
308	Permanent Redirect	Yes (cached)	Yes (preserved)	Permanent redirect that must keep the HTTP method
304	Not Modified	N/A	N/A	Cached version is still valid (conditional request)

For SEO, use 301 for permanent URL changes. Google transfers ranking signals from the old URL to the new one. Use 302 or 307 for temporary situations where the old URL should keep its ranking. The key distinction between 301/302 and 307/308 is method preservation - 301 and 302 allow the browser to change a POST into a GET during the redirect, while 307 and 308 require the original method to be used. This matters for API endpoints that accept POST data.

How Status Codes Affect SEO and Crawl Budget

Search engine crawlers treat status codes differently. Google allocates a crawl budget to each site - the number of pages Googlebot will fetch within a given period. Returning the wrong status code can waste that budget or cause pages to fall out of the index.

According to Google's developer documentation, when Googlebot encounters a 404 it eventually removes that URL from the index, though this can take months. A 410 Gone signals permanent removal and is processed faster. Soft 404s - pages that return 200 OK but display "page not found" content - are particularly harmful. In 2025, Google's Gary Illyes confirmed that soft 404s consume crawl budget just like real pages, even though they return a success code. If 10% of crawled URLs are soft 404s, that is 10% of the crawl budget wasted on non-existent content.

A chain of 301 redirects (A redirects to B, B redirects to C) dilutes link equity and slows down crawling. Keep redirect chains to a single hop where possible. For decoding and debugging URL-encoded query strings during redirect troubleshooting, a URL decoder helps isolate where things break.

Status Codes and Caching

Not every response can be cached. The HTTP spec defines which status codes are cacheable by default, meaning a cache can store the response without explicit Cache-Control headers. Understanding this prevents stale data bugs and unnecessary server load.

Code	Cacheable by Default?	Notes
200	Yes	Can be cached unless Cache-Control says otherwise
301	Yes	Browsers cache permanently - be careful with these
302	No (usually)	Not cached unless Cache-Control explicitly allows it
304	N/A	Confirms cached version is current
404	Technically yes	Can be cached, but usually not desired
500	No	Errors should not be cached

The 304 Not Modified code is central to conditional caching. The client sends an If-None-Match (ETag) or If-Modified-Since header, and if the resource has not changed, the server returns 304 with no body, saving bandwidth. This is how CDNs avoid re-transferring unchanged assets on every request.

What Is 103 Early Hints?

103 Early Hints (RFC 8297) lets the server send a preliminary response before the final 200 OK. This is useful when the server needs time to generate the full response - it can tell the browser to start preloading CSS, fonts, or JavaScript in the meantime. Chrome has supported Early Hints since version 103, and Firefox and Edge also support it. According to Cloudflare, Early Hints can shave nearly a full second off Largest Contentful Paint (LCP) scores by letting the browser fetch critical resources during server think time rather than waiting idle. Support is limited to HTTP/2 and HTTP/3 connections.

206 Partial Content and Range Requests

The 206 Partial Content code means the server is delivering only part of a resource, in response to a Range header from the client. This powers resumable downloads and video streaming - a browser can request bytes 1000-2000 of a video file, and the server returns just that chunk with a Content-Range header. If a download is interrupted, the client can resume from where it left off instead of starting over. Media players rely on this for seeking to arbitrary positions in audio and video files.

Fun and Notable Codes

Code	Name	Origin
418	I'm a Teapot	RFC 2324 (1998 April Fools joke - Hyper Text Coffee Pot Control Protocol)
451	Unavailable For Legal Reasons	Named after Ray Bradbury's Fahrenheit 451 - used when content is censored or blocked by legal demand
420	Enhance Your Calm	Used by Twitter's old API for rate limiting (unofficial, never registered with IANA)
103	Early Hints	RFC 8297 - allows preloading resources before the final response arrives
402	Payment Required	Reserved for future use since HTTP/1.1 in 1997 - still has no official definition, though some APIs use it for payment or quota limits

418 was never intended for production use, but it has taken on a life of its own. Google once returned 418 on google.com/teapot as an Easter egg. The code is specifically excluded from the IANA registry as a permanent joke, but developers still reference it in documentation and error-handling tutorials.

Quick Debugging Checklist

When an API call fails, checking the status code narrows down the problem fast:

Getting 4xx errors? The problem is on the client side. Check the request URL, headers, authentication token, and request body. A JSON Formatter helps validate that the request payload is well-formed JSON. For JWT tokens, decode them to check expiry and claims.

Getting 5xx errors? The problem is on the server side. Check server logs, database connections, and resource limits. A 502 or 504 often points to a reverse proxy or load balancer that cannot reach the upstream application. A 503 usually means the server is overloaded or in maintenance mode - check the Retry-After header for when to try again.

Getting unexpected redirects? Trace the redirect chain with curl -vL to see each hop. Check whether 301 or 302 is used - a 302 where a 301 is intended wastes crawl budget and does not transfer link equity. For looking up Content-Type values returned in response headers, the MIME Types Reference has a searchable list.

Sources

• IANA - HTTP Status Code Registry
• RFC 9110 - HTTP Semantics (IETF, June 2022)
• MDN Web Docs - HTTP Response Status Codes
• Google - How HTTP Status Codes Affect Crawlers
• Cloudflare - Early Hints and Website Load Times
• RFC 8297 - 103 Early Hints