When building APIs, web applications, or microservices, understanding HTTP error codes is essential. These status codes communicate what happened during a client–server request cycle. Proper handling of HTTP status codes improves debugging, user experience, SEO, and overall system reliability.
This guide explains all major HTTP error codes, grouped by category, with practical examples for developers.
1xx – Informational Responses
These status codes indicate that the request was received and the process is continuing.
100 Continue
The server has received the request headers and the client should proceed with the request body.
101 Switching Protocols
The server is switching protocols as requested by the client (for example, HTTP to WebSocket).
102 Processing
The server has received and is processing the request, but no response is available yet.
These are rarely seen in everyday API debugging.
2xx – Success Status Codes
These indicate that the request was successfully received and processed.
200 OK
The request succeeded. This is the most common success response.
201 Created
The request resulted in a new resource being created. Common in POST requests.
202 Accepted
The request has been accepted but is still being processed asynchronously.
204 No Content
The request was successful, but there is no content to return.
3xx – Redirection Status Codes
These indicate that further action is required by the client.
301 Moved Permanently
The resource has permanently moved to a new URL.
302 Found
The resource is temporarily located at another URL.
304 Not Modified
The resource has not changed since the last request. Used for caching.
Redirection status codes are important for SEO and caching strategies.
4xx – Client Error Codes
These indicate that the issue is on the client side.
400 Bad Request
The server cannot process the request due to malformed syntax or invalid input.
Common causes:
Missing required fields
Invalid JSON format
Incorrect query parameters
401 Unauthorized
Authentication is required and has failed or not been provided.
This usually means:
Missing token
Expired token
Invalid credentials
403 Forbidden
The client is authenticated but does not have permission to access the resource.
Authentication confirms identity. Authorization controls access.
404 Not Found
The requested resource does not exist.
Common causes:
Incorrect URL
Deleted resource
Invalid route
405 Method Not Allowed
The HTTP method is not allowed for the requested endpoint.
Example:
Sending POST to an endpoint that only accepts GET.
406 Not Acceptable
The server cannot produce a response matching the Accept headers sent by the client.
408 Request Timeout
The client took too long to send a request.
409 Conflict
The request conflicts with the current state of the server.
Example:
Creating a resource that already exists
Duplicate email during registration
410 Gone
The resource has been permanently removed.
413 Payload Too Large
The request body is too large for the server to process.
415 Unsupported Media Type
The server does not support the content type of the request.
Example:
Sending XML when the server expects JSON.
422 Unprocessable Entity
The request is well-formed but contains semantic errors.
Common in validation errors for APIs.
429 Too Many Requests
The client has sent too many requests in a given time.
Often related to rate limiting.
5xx – Server Error Codes
These indicate that the problem is on the server side.
500 Internal Server Error
A generic error when something unexpected happens on the server.
This often means:
Unhandled exceptions
Null reference errors
Crashed service
501 Not Implemented
The server does not support the functionality required to fulfill the request.
502 Bad Gateway
The server received an invalid response from an upstream server.
Common in microservices architectures.
503 Service Unavailable
The server is currently unable to handle the request.
Possible reasons:
Maintenance
Server overload
504 Gateway Timeout
The upstream server failed to send a request in time.
505 HTTP Version Not Supported
The server does not support the HTTP protocol version used in the request.
How to Handle HTTP Error Codes Properly
- Return Meaningful Messages
Instead of returning only status codes, include helpful error messages.
Example:
{
"error": "Email already exists",
"code": 409
}
- Use Proper Status Codes
Do not return 200 for errors. Follow REST standards.
- Log Server Errors
Always log 5xx errors with detailed context.
- Validate Input Early
Prevent 500 errors by validating user input before processing.
- Implement Rate Limiting
Use 429 responses to protect your API.
Common Developer Mistakes With HTTP Errors
Using 500 for validation errors instead of 400 or 422
Returning 200 even when an operation fails
Exposing sensitive server details in error messages
Not handling 404 routes properly
Why Understanding HTTP Error Codes Matters
For backend developers:
Improves API reliability
Makes debugging easier
Supports scalable architecture
For frontend developers:
Enables better error handling
Improves user feedback
Prevents application crashes
For DevOps engineers:
Helps monitor service health
Assists in alert configuration
Conclusion
HTTP error codes are the foundation of web communication. Whether you are building REST APIs, microservices, or full-stack applications, understanding status codes is critical.
Use the correct status code for each situation. Combine it with structured error responses and proper logging. This ensures better performance, improved user experience, and easier maintenance.
Mastering HTTP status codes is not optional for professional developers. It is a core skill in modern web development.
Top comments (0)