HTTP Status Codes Explained: 40+ HTTP Status Codes Every Developer Should Know

When a browser opens a website or an application sends a request to an API, the server returns an HTTP response. One of the most important pieces of that response is the HTTP status code.

You have probably seen codes such as 200 OK, 404 Not Found, 401 Unauthorized, or 500 Internal Server Error.

These codes help clients, developers, monitoring systems, and API consumers understand what happened to a request.

Simple Definition: An HTTP status code is a three-digit number returned by an HTTP server to indicate the result or current state of a request.

Why Are HTTP Status Codes Important?

Status codes provide a standardized way for servers to communicate outcomes.

For example:

GET /api/users/25
        |
        v
   HTTP Server
        |
        v
200 OK
  

A client can use the status code to decide whether a request succeeded, requires another action, failed because of invalid input, or failed because of a server-side problem.

The Five Main HTTP Status Code Classes

HTTP status codes are grouped into five classes based on their first digit.

Range Class General Meaning
100–199 Informational Request received or processing information
200–299 Success Request was successfully handled
300–399 Redirection Further action may be required
400–499 Client Error Request could not be fulfilled due to a client-side issue
500–599 Server Error Server encountered a problem processing the request

HTTP Status Codes Cheat Sheet

Code Meaning Common Use
100ContinueInterim response
101Switching ProtocolsProtocol upgrade
200OKSuccessful request
201CreatedResource created
202AcceptedRequest accepted for processing
204No ContentSuccessful response without a body
301Moved PermanentlyPermanent redirect
302FoundTemporary redirect
304Not ModifiedConditional request has no newer representation
307Temporary RedirectTemporary redirect preserving method
308Permanent RedirectPermanent redirect preserving method
400Bad RequestMalformed or invalid request
401UnauthorizedAuthentication required or failed
403ForbiddenRequest understood but not permitted
404Not FoundResource not found
405Method Not AllowedHTTP method not supported for resource
408Request TimeoutServer timed out waiting for request
409ConflictConflict with resource state
410GoneResource intentionally no longer available
413Content Too LargeRequest body exceeds permitted size
415Unsupported Media TypeUnsupported request format
422Unprocessable ContentContent understood but cannot be processed
429Too Many RequestsRate limit exceeded
500Internal Server ErrorUnexpected server failure
501Not ImplementedServer does not support required functionality
502Bad GatewayGateway received an invalid upstream response
503Service UnavailableService temporarily unavailable
504Gateway TimeoutGateway timed out waiting for upstream

1xx Informational Status Codes

100-level status codes are informational responses. They generally indicate that the request has been received and processing can continue.

100 Continue

The server indicates that the initial part of the request has been received and the client can continue sending the request.

101 Switching Protocols

This response indicates that the server agrees to switch to a different protocol according to the client's request.



2xx Success Status Codes

200-level status codes indicate successful handling of a request.

200 OK

200 OK is one of the most commonly encountered HTTP status codes.

It generally indicates that the request was successfully processed.

Example:

GET /api/users/25

HTTP/1.1 200 OK
  

201 Created

201 Created indicates that a new resource has been created successfully.

It is commonly used after POST requests that create resources.

POST /api/users

HTTP/1.1 201 Created
  

202 Accepted

202 Accepted indicates that the request has been accepted for processing, but processing may not be complete yet.

This can be useful for asynchronous operations.

204 No Content

204 No Content indicates successful processing when the response does not need to contain a message body.

For example, an API might return 204 after successfully deleting a resource.

3xx Redirection Status Codes

300-level status codes indicate that additional action may be required to complete a request.

301 Moved Permanently

301 indicates that a resource has been permanently moved to a different location.

Example:

https://example.com/old-page
        ↓
https://example.com/new-page
  

302 Found

302 Found indicates a temporary redirection in modern HTTP usage.

304 Not Modified

304 Not Modified is used with conditional requests. It tells the client that its cached representation can still be used because the resource has not changed according to the request's conditions.

307 Temporary Redirect

307 Temporary Redirect indicates a temporary redirect while preserving the request method and request body semantics.

308 Permanent Redirect

308 Permanent Redirect indicates a permanent redirect while preserving the request method and request body semantics.

4xx Client Error Status Codes

400-level responses generally indicate a problem with the request from the client side. That does not necessarily mean the person using the client made a mistake; it means the request cannot be fulfilled due to the request or its context.

400 Bad Request

400 Bad Request is commonly returned when the server cannot process a malformed or invalid request.

Example:

POST /api/users

{
  "email": 
}
  

The request body is malformed, so the server may return 400.

401 Unauthorized

401 Unauthorized is commonly used when valid authentication credentials are required but are missing or invalid.

Example:

GET /api/profile

HTTP/1.1 401 Unauthorized
  

Important: The name can be confusing. In API security discussions, 401 generally relates to authentication, not simply permission.

403 Forbidden

403 Forbidden indicates that the server understood the request but refuses to authorize it.

For example, a normal user may authenticate successfully but still receive 403 when trying to access an administrator-only resource.

404 Not Found

404 Not Found means that the server cannot find a current representation for the requested resource.

Example:

GET /api/users/99999

404 Not Found
  

405 Method Not Allowed

405 Method Not Allowed indicates that the request method is known by the server but is not allowed for the requested resource.

For example, an endpoint might support GET but not DELETE.

408 Request Timeout

408 Request Timeout indicates that the server did not receive a complete request within the time it was prepared to wait.

409 Conflict

409 Conflict indicates that the request conflicts with the current state of the target resource.

For example, an API could use 409 when attempting to create a resource that conflicts with an existing unique record, depending on the API design.

410 Gone

410 Gone indicates that the requested resource is no longer available and that the condition is likely to be permanent.

413 Content Too Large

413 Content Too Large indicates that the request content exceeds a limit defined by the server.

This can occur when uploading a file or sending a large request body.

415 Unsupported Media Type

415 Unsupported Media Type indicates that the server does not support the media format of the request.

For example, an endpoint expecting JSON might reject an unsupported request format.

422 Unprocessable Content

422 Unprocessable Content indicates that the server understood the content type and syntax but could not process the contained instructions or data.

For example, a request might contain valid JSON but fail application-level validation.

429 Too Many Requests

429 Too Many Requests is commonly used when the client has sent too many requests within a defined period.

This is especially relevant to APIs that implement rate limiting.

5xx Server Error Status Codes

500-level status codes generally indicate a problem on the server side while processing a valid request.

500 Internal Server Error

500 indicates an unexpected server-side error.

Example:

GET /api/orders

HTTP/1.1 500 Internal Server Error
  

Possible causes include:

  • Unhandled application exceptions
  • Unexpected dependency failures
  • Programming errors
  • Configuration problems

501 Not Implemented

501 Not Implemented indicates that the server does not support the functionality required to fulfill the request.

502 Bad Gateway

502 Bad Gateway usually occurs when a server acting as a gateway or proxy receives an invalid response from an upstream server.

Client
  |
  v
Reverse Proxy
  |
  v
Application Server
  |
  X
Invalid / Failed Response

Proxy → 502
  

503 Service Unavailable

503 Service Unavailable indicates that the server is currently unable to handle the request, often due to temporary overload, maintenance, or another temporary condition.

504 Gateway Timeout

504 Gateway Timeout indicates that a gateway or proxy did not receive a timely response from an upstream server.

Client
  |
  v
Gateway
  |
  v
Backend
  |
  |
  |------ No timely response
  |
Gateway → 504
  

401 vs 403: What Is the Difference?

This is one of the most common interview questions.

401 403
Authentication is missing or invalid Request is understood but not authorized
Identity has not been successfully established Identity may be known, but access is denied
Example: expired or missing credentials Example: normal user requesting admin-only data

404 vs 410

Both codes relate to missing resources, but their meaning differs.

404 Not Found indicates that the server cannot find a current representation for the resource.

410 Gone indicates that the resource is no longer available and that this is intended to be permanent.

500 vs 502 vs 503 vs 504

Code Typical Problem
500 Unexpected internal server problem
502 Gateway/proxy received an invalid upstream response
503 Service temporarily unavailable
504 Gateway/proxy timed out waiting for upstream

HTTP Status Codes in REST APIs

Correct status codes make REST APIs easier to understand and consume.

For example:

GET    /users/10      → 200
POST   /users         → 201
PATCH  /users/10      → 200 or 204
DELETE /users/10      → 204
GET    /users/999     → 404
POST   /users         → 400 / 422
GET    /admin/report  → 401 / 403
GET    /users         → 429
GET    /users         → 500
  

The exact status selected depends on the semantics of the API and its application rules.

HTTP Status Codes and Frontend Applications

Frontend applications can use status codes to decide what to display or what action to perform.

For example:

if (response.status === 200) {
    // Show data
}

if (response.status === 401) {
    // Ask user to log in
}

if (response.status === 403) {
    // Show access denied message
}

if (response.status === 404) {
    // Show not found message
}

if (response.status === 500) {
    // Show generic server error
}
  

This allows applications to handle different outcomes more intelligently.

HTTP Status Codes and JavaScript Fetch

One important detail is that the Fetch API does not automatically reject a promise merely because an HTTP response has a 4xx or 5xx status.

Developers should inspect the response status or the ok property.

fetch("/api/users")
  .then(response => {
    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    return response.json();
  })
  .then(data => {
    console.log(data);
  })
  .catch(error => {
    console.error(error);
  });
  

HTTP Status Codes and API Error Handling

A good API should combine an appropriate status code with a useful response body when additional information is appropriate.

For example:

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": "validation_error",
  "message": "Email address is invalid",
  "field": "email"
}
  

This is generally more useful to a frontend than returning only a number.

Should You Use 200 for Every API Response?

Using 200 for every situation is generally a poor API design choice.

Status codes exist to communicate meaningful outcomes.

For example, returning 200 for a failed authentication attempt makes it harder for clients, monitoring tools, developers, and intermediaries to understand what happened.

Use status codes according to the semantics of the operation and your API design.

How Developers Debug HTTP Status Codes

When an application returns an unexpected status code, inspect the complete request and response.

Useful information includes:

  • HTTP method
  • Request URL
  • Request headers
  • Request body
  • Status code
  • Response headers
  • Response body
  • Server logs
  • Reverse-proxy logs
  • Application logs

Browser developer tools, Postman, curl, server logs, and monitoring systems can all help identify the cause.

Example: Debugging a 404

Suppose your frontend requests:

GET /api/user/25
  

but the API actually defines:

GET /api/users/25
  

The difference between user and users could result in a 404.

Always check the actual endpoint, routing configuration, base URL, and deployment environment.

Example: Debugging a 401

Suppose a protected endpoint returns 401.

Check:

  1. Whether credentials were included.
  2. Whether the credentials are valid.
  3. Whether the expected authentication scheme was used.
  4. Whether the token has expired.
  5. Whether the server received the authentication header.

Example: Debugging a 403

If authentication succeeds but the server returns 403, inspect authorization rules.

Common questions include:

  • Does the user have the required role?
  • Does the account have the required permission?
  • Is the requested resource restricted?
  • Is a policy blocking the action?

Example: Debugging a 502

A 502 often points to a problem between a proxy and an upstream service.

Browser
   |
   v
Nginx / Reverse Proxy
   |
   v
Node.js / Python / PHP Backend
  

Possible causes can include:

  • Backend process stopped
  • Incorrect upstream address
  • Connection failure
  • Malformed upstream response
  • Deployment problem

Example: Debugging a 503

A 503 can indicate that a service is temporarily unavailable.

Possible causes include:

  • Maintenance
  • Application overload
  • Unavailable backend service
  • Health-check failure
  • Deployment transition

Example: Debugging a 504

A 504 usually means a gateway or proxy waited for an upstream response but did not receive one within the relevant timeout.

Investigate:

  • Backend response time
  • Database performance
  • Network connectivity
  • Proxy timeout configuration
  • Long-running operations

HTTP Status Codes Interview Questions

What does HTTP 200 mean?

It generally means that the request was successfully processed.

What does HTTP 201 mean?

It indicates that a resource was successfully created.

What does HTTP 204 mean?

It indicates successful processing with no response content.

What does HTTP 301 mean?

It indicates that a resource has been permanently moved to another location.

What does HTTP 304 mean?

It indicates that the client's cached representation can be reused because the resource has not changed according to the conditional request.

What does HTTP 400 mean?

It generally indicates that the server could not process the request because it was invalid or malformed.

What is the difference between 401 and 403?

401 generally relates to missing or invalid authentication, while 403 means the request is understood but access is not permitted.

What does HTTP 404 mean?

It means that the requested resource could not be found.

What does HTTP 429 mean?

It indicates that the client has sent too many requests within a relevant time period.

What does HTTP 500 mean?

It indicates an unexpected internal server error.

What does HTTP 502 mean?

It generally indicates that a gateway or proxy received an invalid response from an upstream server.

What does HTTP 503 mean?

It indicates that the server is currently unable to handle the request, often because of a temporary condition.

What does HTTP 504 mean?

It indicates that a gateway or proxy did not receive a timely response from an upstream server.

Frequently Asked Questions

```

What are HTTP status codes?

HTTP status codes are three-digit numbers returned in HTTP responses to communicate the result or state of a request.

How many categories of HTTP status codes are there?

There are five categories: informational (1xx), success (2xx), redirection (3xx), client error (4xx), and server error (5xx).

Which HTTP status code means success?

200 OK is the most common success status code, although other successful codes such as 201 and 204 are used for specific situations.

Which HTTP status code means not found?

404 Not Found indicates that the server cannot find the requested resource.

What is the difference between 401 and 403?

401 generally indicates an authentication problem, while 403 indicates that the request is not authorized.

What does 429 mean?

429 Too Many Requests indicates that a client has exceeded an applicable request rate limit.

What is the difference between 500 and 503?

500 generally indicates an unexpected internal server error, while 503 indicates that the service is currently unavailable and may recover later.

What causes a 502 error?

A 502 often occurs when a gateway or reverse proxy receives an invalid response from an upstream server.

What causes a 504 error?

A 504 occurs when a gateway or proxy waits for an upstream server but does not receive a response within the relevant timeout.

Are HTTP status codes only used for websites?

No. They are also widely used by APIs, backend services, mobile applications, cloud services, proxies, and other HTTP-based systems.

```

Final Thoughts

HTTP status codes are a fundamental part of web development, backend programming, API design, DevOps, and cybersecurity.

You do not need to memorize every status code immediately. Start with the most useful ones:

200  → Success
201  → Created
204  → No Content

301  → Permanent Redirect
302  → Temporary Redirect
304  → Not Modified

400  → Bad Request
401  → Authentication Problem
403  → Forbidden
404  → Not Found
405  → Method Not Allowed
409  → Conflict
422  → Unprocessable Content
429  → Too Many Requests

500  → Internal Server Error
502  → Bad Gateway
503  → Service Unavailable
504  → Gateway Timeout
  

Once these codes become familiar, debugging web applications and REST APIs becomes much easier.

CodeWithAV Developer Tip:

When debugging an API, never look only at the status code. Inspect the request URL, method, headers, body, response body, server logs, and upstream services together.

Related Articles on CodeWithAV

What Is an API? Complete Beginner Guide

REST API Explained With Examples

What Is JSON?

HTTP vs HTTPS Explained

How a Website Works From Browser to Server

Explore More Web Development and Networking Guides

Disclosure: Some links on CodeWithAV may be affiliate links. If you purchase a product or service through an affiliate link, we may earn a commission at no additional cost to you. We aim to recommend products and services based on their relevance to our readers.

CodeWithAV — Learn, Discover & Build.

Adarsh verma

Adarsh verma

CodeWithAV publishes practical technology tutorials, study resources, programming guides, and cybersecurity learning content.