HTTP Status Codes — Complete Reference

Complete reference of all HTTP status codes with descriptions and common use cases. Searchable and filterable. Free developer resource.

45 status codes

100

Continue

The server has received the request headers and the client should proceed to send the request body.

Common use: Used when sending large request bodies. The client sends Expect: 100-continue header first.

101

Switching Protocols

The server is switching protocols as requested by the client via the Upgrade header.

Common use: Used when upgrading an HTTP connection to WebSocket (Upgrade: websocket).

102

Processing

The server has received and is processing the request, but no response is available yet.

Common use: Used in WebDAV to prevent clients from timing out during long-running operations.

103

Early Hints

Used to return some response headers before the final HTTP message.

Common use: Allows the browser to preload resources (CSS, JS) while the server is still preparing the response.

200

OK

The request has succeeded. The meaning depends on the HTTP method used.

Common use: Standard response for successful GET, POST, PUT, and DELETE requests.

201

Created

The request has been fulfilled and a new resource has been created.

Common use: Returned after a successful POST request that creates a new resource. Include a Location header.

202

Accepted

The request has been accepted for processing, but the processing has not been completed.

Common use: Used for async operations like batch processing, queued tasks, or background jobs.

203

Non-Authoritative Information

The returned metadata is not exactly the same as available from the origin server.

Common use: Used by proxies that modify response headers or body, such as CDN transformations.

204

No Content

The server successfully processed the request but is not returning any content.

Common use: Common response for DELETE requests, form submissions, or PUT updates where no body is needed.

206

Partial Content

The server is delivering only part of the resource due to a Range header sent by the client.

Common use: Used for resumable downloads, video streaming, and large file transfers with byte ranges.

207

Multi-Status

Conveys information about multiple resources in situations where multiple status codes might be appropriate.

Common use: Used in WebDAV when a single request affects multiple resources with different outcomes.

300

Multiple Choices

The request has more than one possible response. The user or user agent should choose one.

Common use: Used when a resource is available in multiple formats (e.g., different video encodings).

301

Moved Permanently

The resource has been permanently moved to a new URL. All future requests should use the new URL.

Common use: Domain migration, URL restructuring. Search engines transfer SEO value to the new URL.

302

Found

The resource has been temporarily moved to a different URL. Future requests should still use the original URL.

Common use: Temporary redirects during maintenance, A/B testing, or after form submission (POST-redirect-GET).

303

See Other

The response to the request can be found at another URI using a GET method.

Common use: Used after POST to redirect the client to a confirmation page using GET (PRG pattern).

304

Not Modified

The resource has not been modified since the last request. The client can use its cached version.

Common use: Browser caching with If-Modified-Since or If-None-Match headers. Saves bandwidth.

307

Temporary Redirect

The resource has been temporarily moved. Unlike 302, the method and body are not changed.

Common use: Temporary redirect that preserves the HTTP method (POST stays POST, unlike 302).

308

Permanent Redirect

The resource has been permanently moved. Unlike 301, the method and body are not changed.

Common use: Permanent redirect that preserves the HTTP method. Used for API endpoint migrations.

400

Bad Request

The server cannot process the request due to a client error (malformed syntax, invalid data).

Common use: Invalid JSON body, missing required fields, wrong data types in API requests.

401

Unauthorized

The request requires authentication. The client must authenticate itself to get the requested response.

Common use: Missing or invalid authentication token, expired JWT, wrong API key.

402

Payment Required

Reserved for future use. Originally intended for digital payment systems.

Common use: Sometimes used by APIs to indicate that a paid plan is required to access a feature.

403

Forbidden

The client does not have access rights to the content. Unlike 401, the client's identity is known.

Common use: Accessing admin-only resources, IP-blocked requests, insufficient permissions or roles.

404

Not Found

The server cannot find the requested resource. The URL is not recognized.

Common use: Deleted pages, typos in URLs, resources that never existed. Most common HTTP error.

405

Method Not Allowed

The HTTP method used is not supported for the requested resource.

Common use: Sending POST to a read-only endpoint, or DELETE to a resource that does not support deletion.

406

Not Acceptable

The server cannot produce a response matching the Accept headers sent by the client.

Common use: Requesting application/xml from an API that only returns JSON.

408

Request Timeout

The server timed out waiting for the request from the client.

Common use: Slow client connections, large file uploads on unstable networks.

409

Conflict

The request conflicts with the current state of the server.

Common use: Duplicate resource creation, edit conflicts, version mismatches in optimistic locking.

410

Gone

The resource is permanently gone and will not be available again. Unlike 404, this is intentional.

Common use: Deprecated API endpoints, intentionally removed content. Tells search engines to deindex.

411

Length Required

The server requires the Content-Length header to be set in the request.

Common use: APIs that require a Content-Length header for body parsing or resource allocation.

413

Payload Too Large

The request body is larger than the server is willing to process.

Common use: File upload size limits, API request body limits (e.g., max 10MB JSON payload).

414

URI Too Long

The URL requested by the client is longer than the server is willing to interpret.

Common use: Overly long query strings. Consider using POST with a request body instead.

415

Unsupported Media Type

The media format of the request body is not supported by the server.

Common use: Sending text/plain to an endpoint that expects application/json.

418

I'm a Teapot

The server refuses to brew coffee because it is, permanently, a teapot.

Common use: Defined in RFC 2324 (Hyper Text Coffee Pot Control Protocol) as an April Fools' joke. Sometimes used as an Easter egg.

422

Unprocessable Entity

The request is well-formed but contains semantic errors that prevent processing.

Common use: Validation errors: correct JSON syntax but invalid field values (e.g., negative age, invalid email format).

429

Too Many Requests

The client has sent too many requests in a given amount of time (rate limiting).

Common use: API rate limiting. Check Retry-After header for when to retry.

431

Request Header Fields Too Large

The server is unwilling to process the request because its header fields are too large.

Common use: Oversized cookies, too many headers. Clear cookies or reduce header size.

451

Unavailable For Legal Reasons

The resource is unavailable due to legal demands (censorship, court order).

Common use: GDPR compliance, government censorship, DMCA takedowns. Named after Fahrenheit 451.

500

Internal Server Error

The server encountered an unexpected condition that prevented it from fulfilling the request.

Common use: Unhandled exceptions, crashes, configuration errors. Generic server-side error.

501

Not Implemented

The server does not support the functionality required to fulfill the request.

Common use: Unsupported HTTP methods, features not yet built in the API.

502

Bad Gateway

The server, acting as a gateway or proxy, received an invalid response from an upstream server.

Common use: Reverse proxy (Nginx, Cloudflare) cannot reach the application server. Common in microservices.

503

Service Unavailable

The server is not ready to handle the request. Common causes: maintenance or overload.

Common use: Planned maintenance, server overload, deploys in progress. Check Retry-After header.

504

Gateway Timeout

The server, acting as a gateway or proxy, did not receive a timely response from the upstream server.

Common use: Upstream server is too slow. Common with long-running database queries or external API calls.

505

HTTP Version Not Supported

The server does not support the HTTP version used in the request.

Common use: Client using HTTP/2 or HTTP/3 with a server that only supports HTTP/1.1.

507

Insufficient Storage

The server cannot store the representation needed to complete the request.

Common use: Server disk full, database storage limit reached. Common in WebDAV operations.

511

Network Authentication Required

The client needs to authenticate to gain network access.

Common use: Captive portals in airports, hotels, and public Wi-Fi that require login before internet access.

HTTP Status Codes Reference — Complete Developer Guide

A complete reference of all HTTP status codes from 1xx informational to 5xx server errors. Each entry includes the status code, its official name, a clear description, and real-world use cases. Filter by category or search by code number and description. Bookmark this page as your go-to HTTP status code cheat sheet for web development and API debugging.

seo.httpStatusCodes.p2

Choosing the correct status code for your API responses communicates clear intent to clients. A 200 means the request succeeded, but 201 is more precise for resource creation, and 204 is correct when there is no response body. Using generic 200 for everything forces clients to parse the body to understand what happened.

The most commonly misused status codes are 401 vs 403 (authentication vs authorization), 302 vs 301 (temporary vs permanent redirect), and 400 vs 422 (bad request vs unprocessable entity). Each has a specific semantic meaning defined in the HTTP specification that clients and search engines rely on.

When debugging API errors, the status code is your first diagnostic clue. A 502 or 504 points to issues between your reverse proxy and the upstream server. A 429 means you have hit a rate limit. A 503 typically indicates the server is overloaded or under maintenance. Understanding these codes helps you triage issues faster and communicate problems clearly to your team.

How to Use the HTTP Status Codes Reference

  1. Browse the complete list of HTTP status codes organized by category
  2. Use the search bar to filter by code number or description
  3. Click category tabs (1xx, 2xx, 3xx, 4xx, 5xx) to narrow results
  4. Read the description and common use case for each status code

Understanding HTTP Status Codes

HTTP status codes are three-digit numbers returned by web servers to indicate the outcome of a client request. They are grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client errors), and 5xx (server errors). Understanding these codes is essential for web developers, API designers, and anyone debugging network requests. The most commonly encountered codes are 200 (OK), 301 (Moved Permanently), 404 (Not Found), and 500 (Internal Server Error).

When to Use This Reference

Use this reference when building REST APIs to choose the correct response code, debugging HTTP requests in browser DevTools, or troubleshooting server errors in production logs.

Common Use Cases

  • Choosing the correct response status code when building REST APIs or GraphQL endpoints
  • Debugging HTTP errors in browser DevTools Network tab or server logs
  • Understanding redirect behavior (301 vs 302) when configuring URL routing or domain migrations
  • Troubleshooting rate limiting (429) and server errors (502, 503, 504) in production environments

Expert Tips

  • Use 201 Created instead of 200 OK when a POST request successfully creates a new resource — it is semantically correct and helps API consumers.
  • Return 204 No Content for successful DELETE requests that have no response body, rather than 200 with an empty object.
  • Include a Retry-After header with 429 and 503 responses so clients know when they can retry their request.

Frequently Asked Questions

What is the difference between 401 and 403?
401 Unauthorized means the client has not authenticated (no credentials or invalid credentials). 403 Forbidden means the client is authenticated but does not have permission to access the resource.
When should I use 301 vs 302 redirect?
301 is for permanent moves (URL changed forever, search engines update their index). 302 is for temporary redirects (original URL is still valid). Use 301 for domain migrations and 302 for maintenance redirects.
What does 429 Too Many Requests mean?
429 indicates rate limiting. The client has sent too many requests in a given time period. Check the Retry-After response header to know when you can make requests again.
What is the difference between 502 and 504?
502 Bad Gateway means the proxy received an invalid response from the upstream server. 504 Gateway Timeout means the proxy did not receive any response in time. Both indicate upstream server issues.

Related Tools

VultrSponsored

Vultr