HTTP Status Codes Explained: A Practical Guide to Understanding 200, 301, 400, 401, 403, 404 and 500 Errors

If you work with websites, APIs, or web applications, you've probably seen these messages more times than you can count.

HTTP status codes are part of everyday web development. They tell us whether a request was successful, whether something needs attention, or whether the server encountered a problem.

The interesting part is that you don't need to be an experienced developer to understand them.

In this guide, we'll explain HTTP status codes in simple language, explore the most commonly used codes, and walk through practical examples to help you understand and troubleshoot them.

What Are HTTP Status Codes?

HTTP stands for Hypertext Transfer Protocol. It is the communication protocol that allows browsers, servers, and applications to exchange information over the web.

Imagine visiting an online store.

1. You open the website.

2. Your browser sends a request to the server.

3. The server processes your request.

4. The server sends a response back to your browser.

An HTTP status code is a three-digit number included in that response. It tells your browser or application what happened to the request.

For example:

• 200 OK: Everything worked successfully.

• 301 Moved Permanently: The requested resource has moved to another URL.

• 400 Bad Request: The request contains something invalid.

• 401 Unauthorized: Authentication is required or has failed.

• 403 Forbidden: Access to the requested resource is not permitted.

• 404 Not Found: The requested resource could not be found.

• 500 Internal Server Error: Something went wrong on the server.

Think of status codes as short messages between your browser and the server. They help developers understand what happened without having to inspect every part of the application.

Understanding the Five Categories of HTTP Status Codes

HTTP status codes are divided into five main categories based on their first digit.

1. Informational Responses (100–199)

These codes indicate that the server has received the request and that communication is continuing.

Some examples include:

• 100 Continue: The server has received the initial request headers and the client can continue sending the request.

• 101 Switching Protocols: The server is switching to another communication protocol.

These responses are generally less visible during everyday website browsing.

2. Successful Responses (200–299)

These codes indicate that the request was successfully received, understood, and processed.

Common examples:

• 200 OK: The request completed successfully.

• 201 Created: A new resource was successfully created.

• 202 Accepted: The request was accepted for processing, but processing may not be complete.

• 204 No Content: The request succeeded, but there is no response body to return.

For example, when a user creates an account through an API, the server might return:

{
  "status": 201,
  "message": "User created successfully",
  "data": {
    "id": 105,
    "name": "John"
  }
}

A 201 response is appropriate when the request successfully creates a new resource.

3. Redirection Responses (300–399)

These codes indicate that the requested resource is available elsewhere or that the client needs to take another action to complete the request.

Common examples:

• 301 Moved Permanently: The resource has permanently moved to a new URL.

• 302 Found: The resource is temporarily available at another URL.

• 303 See Other: The client should retrieve another resource using GET.

• 304 Not Modified: The resource has not changed since the client's cached version.

• 307 Temporary Redirect: The client should temporarily use another URL while preserving the request method.

• 308 Permanent Redirect: The resource has permanently moved, preserving the request method.

For example, imagine your website changes its URL:

Old URL:
https://example.com/old-page

New URL:
https://example.com/new-page

A 301 redirect tells browsers and search engines that the page has permanently moved.

This is particularly important for SEO because incorrect redirects can affect how search engines discover and index your website.

4. Client Error Responses (400–499)

These codes indicate that something is wrong with the request sent by the client.

The issue may involve missing information, incorrect parameters, authentication, or access permissions.

Some of the most important client error codes are explained below.

HTTP 400 – Bad Request

A 400 response means the server cannot process the request because it considers the request invalid.

Possible reasons include:

• Invalid request parameters.

• Incorrect JSON formatting.

• Missing required fields.

• Invalid query strings.

• Malformed request headers.

Example:

{
  "name": "John",
  "email": "john@example.com",
}

The trailing comma makes this invalid JSON.

If an API expects valid JSON, it may reject this request with a 400 response.

How to troubleshoot:

• Validate the request payload.

• Check required parameters.

• Verify the Content-Type header.

• Inspect the API documentation.

• Check whether the request contains unexpected values.

HTTP 401 – Unauthorized

A 401 response means the request lacks valid authentication credentials.

For example, imagine accessing a protected API without providing an access token.

The server cannot establish that you are an authenticated user.

Common causes include:

• Missing authentication token.

• Expired access token.

• Invalid username or password.

• Incorrect API key.

• Invalid authentication header.

Example:

GET /api/profile HTTP/1.1
Host: example.com
Authorization: Bearer invalid_token

How to troubleshoot:

• Check whether the access token is included.

• Verify that the token has not expired.

• Confirm the authentication format.

• Generate a new token if required.

HTTP 403 – Forbidden

A 403 response means the server understands the request but refuses to authorize access to the requested resource.

Here is a simple example.

A user successfully logs into an admin dashboard but does not have permission to access the financial reports section.

The user is authenticated, but the application does not authorize that particular action.

Common causes include:

• Insufficient user permissions.

• Role-based access restrictions.

• IP address restrictions.

• Server access rules.

• Security policies blocking the request.

How to troubleshoot:

• Check the user's assigned roles.

• Review application permissions.

• Verify resource-level access controls.

• Inspect server security rules.

Remember the difference:

401 generally relates to authentication, while 403 relates to authorization.

HTTP 404 – Not Found

A 404 response means the requested resource could not be found.

This is one of the most recognizable errors on the internet.

Imagine clicking a link to an article that has been deleted or moved without a proper redirect.

The browser requests the URL, but the server cannot find the requested page.

Common causes include:

• Incorrect URL.

• Deleted web page.

• Broken internal links.

• Incorrect routing configuration.

• Missing API endpoint.

• Incorrect resource ID.

How to troubleshoot:

• Verify the requested URL.

• Check whether the resource exists.

• Review routing configurations.

• Check application logs.

• Configure appropriate redirects when pages move permanently.

For website owners, broken links should be monitored regularly because they create a poor visitor experience and can waste search engine crawling resources.

HTTP 405 – Method Not Allowed

A 405 response indicates that the HTTP method used in the request is not supported for the requested resource.

For example, an API endpoint may support GET requests but not DELETE requests.

DELETE /api/products/100

If the endpoint does not allow DELETE, the server can return 405.

How to troubleshoot:

• Verify supported HTTP methods.

• Review API endpoint documentation.

• Check route definitions.

• Confirm the correct request method.

HTTP 409 – Conflict

A 409 response indicates a conflict with the current state of the resource.

For example, a user may attempt to register an account using an email address that already exists.

The server cannot complete the request because it conflicts with existing data.

HTTP 429 – Too Many Requests

A 429 response indicates that the client has sent too many requests within a specified period.

This commonly occurs when an API implements rate limiting.

For example, an API might allow 100 requests per minute. Sending more than that may result in a 429 response.

How to troubleshoot:

• Check API rate limits.

• Reduce request frequency.

• Implement retry logic.

• Respect the Retry-After header when provided.

• Use caching where appropriate.

5. Server Error Responses (500–599)

These codes indicate that the server failed to fulfill an apparently valid request.

Unlike most 4xx errors, server errors generally require investigation on the backend.

Common examples include:

HTTP 500 – Internal Server Error

A 500 response is a general server-side error.

It means something unexpected happened while processing the request.

Possible causes include:

• Unhandled application exceptions.

• Database connection failures.

• Incorrect server configuration.

• Application bugs.

• Memory or resource exhaustion.

How to troubleshoot:

• Inspect application logs.

• Check server error logs.

• Review recent deployments.

• Verify database connectivity.

• Check environment variables and configuration.

• Identify the underlying exception.

A 500 response does not explain the exact problem. Developers need to inspect the server-side logs to identify the root cause.

HTTP 502 – Bad Gateway

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

For example, a website may use a reverse proxy that communicates with an application server.

If the application server returns an invalid response, the proxy may return 502 to the browser.

HTTP 503 – Service Unavailable

A 503 response means the server is temporarily unable to handle the request.

Possible reasons include:

• Scheduled maintenance.

• Temporary server overload.

• Infrastructure problems.

• Application downtime.

The service may become available again after the underlying issue is resolved.

HTTP 504 – Gateway Timeout

A 504 response occurs when a gateway or proxy does not receive a timely response from an upstream server.

For example, an API request might take too long because a database query is running slowly.

How to troubleshoot:

• Review upstream service health.

• Inspect request processing time.

• Check database performance.

• Review proxy timeout settings.

• Identify slow external API integrations.

HTTP Status Codes Cheat Sheet

Here is a quick reference to the HTTP status codes developers should recognize.

How to Check HTTP Status Codes

You don't need advanced software to inspect HTTP responses. There are several practical ways to check them.

1. Using Browser Developer Tools

Most modern browsers include built-in developer tools.

Follow these steps:

1. Open the website you want to inspect.

2. Press F12 or right-click and select Inspect.

3. Open the Network tab.

4. Reload the page.

5. Select the relevant network request.

6. Look at the Status column or the response headers.

You can inspect the status code, request URL, response headers, timing information, and other useful details.

2. Using the cURL Command

Developers can use cURL to inspect HTTP responses directly from the terminal.

Example:

curl -I https://example.com

This sends a HEAD request and displays the response headers.

To inspect a GET request with response headers:

curl -i https://example.com

You may receive a response similar to:

HTTP/2 200
content-type: text/html
cache-control: max-age=3600

The first line tells you the HTTP response status.

3. Using Online Developer Tools

Online developer tools can simplify everyday development tasks without requiring additional software installations.

You can use online tools for formatting JSON, validating data, encoding URLs, comparing text, and performing other common development tasks.

Explore the free developer utilities available on AgileLogics to simplify your daily workflow.

Common HTTP Status Code Troubleshooting Tips

When an unexpected status code appears, avoid immediately assuming that the server or application is broken.

Follow a systematic troubleshooting approach.

Step 1: Identify the response code

Check the Network tab or API response to understand what happened.

Step 2: Inspect the request

Verify the URL, request method, headers, query parameters, and request body.

Step 3: Check authentication and permissions

For 401 and 403 errors, investigate credentials, tokens, roles, and access policies.

Step 4: Review application logs

For 5xx errors, inspect backend logs and identify the actual exception or infrastructure problem.

Step 5: Check recent changes

Review recent deployments, configuration changes, and dependency updates.

Step 6: Verify the solution

Repeat the request and confirm that the expected response is returned.

This approach helps developers solve problems systematically instead of making random code changes.

Frequently Asked Questions (FAQs)

1. What is the most common HTTP status code?

HTTP 200 OK is one of the most frequently encountered status codes. It indicates that a request was successfully processed.

2. What is the difference between HTTP 401 and 403?

HTTP 401 indicates that valid authentication credentials are missing or unavailable. HTTP 403 indicates that access is not permitted, even when the request is understood by the server.

3. Is HTTP 404 a server error?

No. HTTP 404 belongs to the 4xx client error category. It indicates that the requested resource could not be found.

4. What does HTTP 500 mean?

HTTP 500 indicates an unexpected server-side problem. Developers should inspect application and server logs to identify the root cause.

5. What is the difference between HTTP 301 and 302?

HTTP 301 indicates a permanent redirect, while HTTP 302 indicates a temporary redirect.

6. What does HTTP 429 mean?

HTTP 429 means the client has sent too many requests within a given period. It is commonly associated with API rate limiting.

7. Can HTTP status codes affect SEO?

Yes. Search engines use HTTP responses to understand whether pages are accessible, redirected, or unavailable. Incorrect redirects and unintended server errors can negatively affect crawling and indexing.

8. What is the difference between 4xx and 5xx errors?

4xx errors generally indicate problems with the request or access to a resource. 5xx errors indicate that the server failed to fulfill a request.

Final Thoughts

HTTP status codes may look like simple three-digit numbers, but they provide valuable information about how websites and applications communicate.

Whether you're building an API, troubleshooting a website, managing an eCommerce platform, or learning web development, understanding these codes will make debugging easier and help you identify problems faster.

You don't need to memorize every HTTP status code. Start with the commonly used ones, understand their meaning, and learn how to investigate them when something goes wrong.

The next time you encounter a 401, 404, or 500 error, you'll have a much better idea of where to start.

Keep learning, keep building, and make development simpler with AgileLogics.