404), a name (not found) or a keyword from the description (redirect) into the search box.HTTP status codes are how servers tell clients what happened — but the difference between 301 and 302, or between 401 and 403, decides whether your API is debuggable, your redirects are SEO-friendly, and your security posture is sane. This reference covers the codes you actually meet in production: full informational (1xx), success (2xx), redirect (3xx), client error (4xx) and server error (5xx) ranges, with concise meanings rather than copy-pasted RFC prose.
The first digit groups the code by intent: 1xx is informational and rarely surfaces in app code; 2xx means the request succeeded; 3xx tells the client the resource lives elsewhere; 4xx blames the client for the failure (bad input, missing auth, gone resource); 5xx blames the server. Picking the right code in your own API matters — it's how clients, monitoring systems and search engines decide what to do next.
301 Moved Permanently tells browsers and search engines the new URL is the canonical one — they should update bookmarks and link equity. 302 Found is a temporary redirect — the resource is somewhere else for now but the original URL still belongs. Use 301 for site moves and HTTPS upgrades, 302 for short-term diversions.
401 Unauthorized means the request is missing or has bad credentials — the client should authenticate and retry. 403 Forbidden means the credentials are valid but the user is not allowed to access this resource — re-authenticating won't help. Sending 403 when you mean 401 will hide a fixable client-side problem.
422 Unprocessable Entity means the request was well-formed JSON or XML but failed validation rules (e.g. email format wrong, required field missing). 400 Bad Request means the server couldn't even parse the body. Use 422 for validation errors so clients can distinguish syntax problems from semantic ones.
502 means the proxy or load balancer in front of your app received an invalid response from the upstream server — usually because the app crashed mid-request, exceeded a timeout, or was restarted during deploy. Check upstream logs around the timestamp; it's almost never a problem with the proxy itself.
See also the URL Parser, the JSON Formatter, and the JWT Decoder for related API debugging tools.