HTTP Status Codes
Also Known As
HTTP response codes
status codes
TL;DR
Three-digit codes in HTTP responses that indicate whether a request succeeded, failed, or requires further action.
Explanation
HTTP status codes are grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error). Using correct codes is essential for caching, retry logic, API clients, and debugging. A 200 OK with an error body, or a 500 for a validation failure, breaks every layer that depends on HTTP semantics.
Diagram
flowchart TD
REQ[HTTP Request] --> RANGE{Status range}
RANGE -->|1xx| INFO2[Informational<br/>100 Continue<br/>101 Switching Protocols]
RANGE -->|2xx| SUCCESS[Success<br/>200 OK<br/>201 Created<br/>204 No Content]
RANGE -->|3xx| REDIRECT[Redirect<br/>301 Permanent<br/>302 Temporary<br/>304 Not Modified]
RANGE -->|4xx| CLIENT[Client Error<br/>400 Bad Request<br/>401 Unauthorized<br/>403 Forbidden<br/>404 Not Found<br/>422 Unprocessable<br/>429 Rate Limited]
RANGE -->|5xx| SERVER[Server Error<br/>500 Internal Error<br/>502 Bad Gateway<br/>503 Service Unavailable]
style SUCCESS fill:#238636,color:#fff
style CLIENT fill:#f85149,color:#fff
style SERVER fill:#f85149,color:#fff
style REDIRECT fill:#d29922,color:#fff
style INFO2 fill:#1f6feb,color:#fff
Common Misconception
✗ A 200 OK means everything is fine — many APIs return 200 with an error payload, breaking client error handling.
Why It Matters
Correct status codes drive browser behaviour (caching, redirects), API client retry logic, and monitoring alerts — using 200 for errors silently breaks all of these.
Common Mistakes
- Returning 200 OK with an error body — clients cannot detect the failure without parsing every response.
- Using 500 for validation errors — 422 Unprocessable Entity or 400 Bad Request is correct for client-supplied bad data.
- Returning 404 for authorisation failures — use 403 Forbidden; 404 leaks that the resource exists.
- Not returning 429 Too Many Requests with a Retry-After header for rate-limited responses.
Code Examples
✗ Vulnerable
// 200 OK with error — breaks client error detection:
return response()->json(['error' => 'User not found'], 200); // Wrong
// Correct status codes:
return response()->json(['message' => 'Not found'], 404);
return response()->json(['errors' => $validation], 422);
return response()->json(['message' => 'Forbidden'], 403);
✓ Fixed
// Semantic status codes:
return response()->json($user, 200); // GET success
return response()->json($created, 201); // POST created
return response()->json(null, 204); // DELETE success
return response()->json($errors, 422); // Validation failed
return response()->json(['message' => 'Not found'], 404);
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
30
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 8
Amazonbot 6
Unknown AI 2
Ahrefs 2
Google 1
SEMrush 1
ChatGPT 1
Also referenced
How they use it
crawler 21
Related categories
⚡
DEV INTEL
Tools & Severity
🟡 Medium
⚙ Fix effort: Low
⚡ Quick Fix
Use 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity, 429 Too Many Requests, 500 Internal Server Error — these cover 95% of cases
📦 Applies To
any
web
api
🔍 Detection Hints
200 returned for all errors; 404 for business logic errors; 401 vs 403 confused; 500 returned for validation failures
Auto-detectable:
✗ No
postman
spectral
owasp-zap
⚠ Related Problems
🤖 AI Agent
Confidence: Medium
False Positives: Medium
✓ Auto-fixable
Fix: Low
Context: Function
Tests: Update