HTTP Status Codes Explained
Search and understand HTTP status codes using simple explanations and real-world examples. No jargon — just clear answers to what happened, why, and what to do next.
Browse All Status Codes
Common Confusions
401 vs 403
Think: 401 = "Who are you?", 403 = "I know who you are — still no."
404 vs 410
Use 410 when you've deleted content on purpose and want it removed from search results.
301 vs 302
Use 301 for permanent changes (domain migration). Use 302 for temporary redirects (maintenance).
500 vs 502
502 usually means the app server is down; 500 means it's up but broken.
502 vs 503
503 is intentional and temporary; 502 is an unexpected infrastructure failure.
API Developer Quick Guide
Which code to return from your API endpoints — at a glance.
What Are HTTP Status Codes?
HTTP status codes are three-digit numbers a server sends back every time your browser or app makes a request. They tell you — in a standardised way — whether the request succeeded, failed, or needs something from you. The first digit puts them into five groups: 1xx (the server is still working on it), 2xx (success), 3xx (redirected to another URL), 4xx (something wrong with your request), and 5xx (the server had a problem). Every web request returns one of these codes, even when a page loads perfectly (that's a 200 OK).
HTTP Status Codes Complete List — By Group
The full list of HTTP status codes spans five ranges. 1xx codes (100–199) are informational — you rarely see them in normal use. 2xx codes (200–299) confirm success: 200 OK is the standard response, 201 Created means something new was made, and 204 No Content means the action worked but there is nothing to return. 3xx codes (300–399) are redirects: 301 Moved Permanently tells search engines to update their index, while 302 Found is a temporary detour. 4xx codes (400–499) point to a problem with the request itself — 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, and 429 Too Many Requests are the most common. 5xx codes (500–599) mean the server ran into a problem: 500 Internal Server Error, 502 Bad Gateway, and 503 Service Unavailable are the ones you encounter most.
HTTP Status Codes for REST APIs
When building or consuming a REST API, using the right status code matters. Return 200 OK for successful reads and updates, 201 Created after a POST that makes a new resource (include a Location header pointing to it), and 204 No Content after a successful DELETE. For client errors: 400 for bad input, 401 for missing authentication, 403 when the user is authenticated but lacks permission, 404 when the resource does not exist, 409 for conflicts (duplicate records, version mismatches), 422 for validation failures that pass format checks but fail business rules, and 429 when rate limiting kicks in. Always use 500 as a catch-all for unexpected server failures, and never expose stack traces in the response body.
Understanding 404 Not Found
404 is the most recognised HTTP status code. It simply means the server cannot find anything at the URL you requested. This does not mean the server is broken — it is working fine and telling you the resource does not exist there. Common causes: a mistyped URL, a page that was deleted without setting up a redirect, or a link on another website pointing to an old address. For site owners, every unhandled 404 is a lost visitor. Audit your 404s regularly using Google Search Console and set up 301 redirects for any pages you have moved or renamed.
Understanding 500 Internal Server Error
500 is the server's catch-all for unexpected failures. When an application throws an unhandled exception, the server returns 500 rather than exposing the raw error. This is always a server-side problem — never caused by the visitor. As a user, wait a few minutes and try again. As a developer, check your error logs immediately: the root cause is almost always an unhandled exception, a failed database connection, or a misconfigured environment variable. Never return a 500 with a stack trace visible to end users.
Understanding 429 Too Many Requests
429 is the rate limiting code. It means you (or your app) has sent too many requests in a given time window and the server has temporarily blocked further requests to protect itself. Check the Retry-After header in the response — it tells you exactly when you can try again. If you are building an API client, implement exponential backoff: wait progressively longer after each consecutive 429 instead of retrying at a fixed interval. If you are a legitimate user hitting this on a website, simply wait a minute before refreshing.
301 vs 302 — Permanent vs Temporary Redirects
Both 301 and 302 send your browser to a different URL, but they carry very different signals for search engines and browsers. A 301 Moved Permanently tells search engines to transfer all ranking signals to the new URL and update their index. Browsers cache it, so future visits go straight to the new address. A 302 Found is temporary: search engines keep the original URL indexed and browsers do not cache it. Use 301 when moving a page for good (domain migrations, URL restructuring, HTTP to HTTPS). Use 302 for maintenance windows or short-term A/B tests where the original URL will return.
How to Fix Common HTTP Errors
To fix a 404: check the URL for typos, search the site for the content, or contact the site owner. If you run the site, add a 301 redirect from the old URL to the new one. To fix a 403: confirm you are logged in with an account that has the right permissions. To fix a 500: wait and refresh — if it persists, contact support or check server logs. To fix a 502 or 503: the server is temporarily down or overloaded; wait a few minutes. To fix a 429: slow down your requests and respect the Retry-After header. For site owners, the most impactful things you can do are: monitor error rates with an alerting tool, add structured error logging, and always return meaningful error messages alongside the correct status code.